6.0.0-git
2019-03-20

[#10423] Horde_Auth_Sql 1.0.4 expiration feature severly broken - if I am not completely wrong
Summary Horde_Auth_Sql 1.0.4 expiration feature severly broken - if I am not completely wrong
Queue Horde Framework Packages
Queue Version Git master
Type Bug
State Resolved
Priority 1. Low
Owners Horde Developers (at)
Requester lang (at) b1-systems (dot) de
Created 2011-08-11 (2778 days ago)
Due
Updated 2011-08-12 (2777 days ago)
Assigned 2011-08-11 (2778 days ago)
Resolved 2011-08-12 (2777 days ago)
Milestone
Patch No

History
2011-08-12 10:07:30 Ralf Lang (B1 Systems GmbH) Comment #6
State ⇒ Resolved
Reply to this comment

[Show Quoted Text - 21 lines]
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?
2011-08-12 10:02:07 Git Commit Comment #5 Reply to this comment
Changes have been made in Git for this ticket:

[#10423] Horde_Auth_Sql 1.0.4 expiration feature - make resetPassword 
and addUser properly set expiration values if needed

  1 files changed, 21 insertions(+), 1 deletions(-)
http://git.horde.org/horde-git/-/commit/484c21ca61a13eb7998eea2748c28b32aafe5ceb
2011-08-12 08:57:38 Git Commit Comment #4 Reply to this comment
Changes have been made in Git for this ticket:

[#10423] Horde_Auth_Sql 1.0.4 expiration feature - repairs updateUser issues

  1 files changed, 20 insertions(+), 14 deletions(-)
http://git.horde.org/horde-git/-/commit/c7b0fd28d3363b7fb1adc0ce089a5a06cb8460a9
2011-08-12 07:33:32 Ralf Lang (B1 Systems GmbH) Comment #3 Reply to this comment

[Show Quoted Text - 11 lines]
Wasn't aware of that. I've always only known positive timestamps.
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)
Not sure about this, but it might be due to the errors described in (4).
Moreover, time gives me a positive value, but that formular involving 
time and mktime returns a negative integer. If Timestamps are a number 
of seconds since 1970, this should be before 1970 but then the formula 
is broken. I'd rather ditch the formula in favor of 
http://www.php.net/manual/en/class.datetime.php as we're PHP 5.2+ now.

[Show Quoted Text - 21 lines]
Yes. Adding it makes saving work but then horde expires my user as any 
negative timestamp is before $now.

[Show Quoted Text - 10 lines]
I'll do.
2011-08-11 23:57:32 Michael Rubinsky Comment #2
Assigned to Horde DevelopersHorde Developers
State ⇒ Assigned
Reply to this comment

[Show Quoted Text - 9 lines]
Not sure why that's a problem? Unix timestamps are signed 32 bit integers.
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)
Not sure about this, but it might be due to the errors described in (4).
3) The hard expiration timestamp is calculated via soft_expiration_window.
Appears to be a bug.
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)
If you are talking about Horde_Auth_Sql#updateUser(), then I agree - 
this doesn't look correct. Looks like it was included within the else 
clause erroneously. Also, it appears it could be a copy/paste error, 
as the hard expiration calc is using the $date variable that was 
already incremented by soft exp.
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).
Looks like it's missing the $query portion for hard expiration.
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.
Sounds like a bug.
I think I can fix this as I'm working on #10387 already.
Go for it :)

2011-08-11 23:19:32 Ralf Lang (B1 Systems GmbH) Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ Horde_Auth_Sql 1.0.4 expiration feature severly broken - if I am not completely wrong
Queue ⇒ Horde Framework Packages
Milestone ⇒
Patch ⇒ No
Reply to this comment
Excuse me if I got something wrong and this is all bogus.

The Horde_Auth_Sql driver provides account password expiration in a 
soft (warn) and hard (lock) flavour.

To me this feature looks totally broken in Horde 4.

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.

I have checked this against 1.0.4 after I had initial issues with git, 
where I checked in my own additions today.

What puzzles me is the math bit. I think it dates back to horde3 and I 
doubt it could be broken for so long without anybody noticing.

I think I can fix this as I'm working on #10387 already.

Just want somebody to verify I'm not chasing my very own installation 
troubles.

Saved Queries