[Tickets #10423] Re: Horde_Auth_Sql 1.0.4 expiration feature severly broken - if I am not completely wrong

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/10423
------------------------------------------------------------------------------
  Ticket             | 10423
  Updated By         | Ralf Lang (B1 Systems GmbH) <lang at b1-systems.de>
  Summary            | Horde_Auth_Sql 1.0.4 expiration feature severly broken
                     | - if I am not completely wrong
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
-State              | Assigned
+State              | Resolved
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Horde Developers
------------------------------------------------------------------------------


Ralf Lang (B1 Systems GmbH) <lang at b1-systems.de> (2011-08-12 10:07) wrote:

> 1) The migration file creates the soft and hard timestamp fields as  
> signed int 11 rather than unsigned. (tested on mysql)
>
> 2) The calculation routine produces a negative value for the soft  
> and hard expiration timestamp. This means users changing password  
> immediately expired accounts if it wasn't for 5)
>
> 3) The hard expiration timestamp is calculated via soft_expiration_window.
>
> 4) The hard expiration timestamp is completely ignored if soft  
> expiration is not configured - is this intended? The calculation of  
> hard_expiration_date at least looks a little like this could be true  
> - but see 3)
>
> 5) If hard expiration is configured, changing users is completely  
> broken because the generated SQL has more values than fields (or  
> other way around, the last value is treated as a key).
>
> 6) The addUser routine doesn't initialize these additional fields.  
> As a result, all accounts last forever until the user changes  
> credentials for the first time.

2-6) fixed.
1) Not a bug, though I see no need for expiration timestamps before  
1970 in this table.

Also added some sanity checking such that a user cannot configure  
expiration windows when there is no field configured.

Can we wait with changelog / release till I complete the lock / fail  
count feature today or monday?