6.0.0-git
2019-03-23

[#3386] logouts due to imp_key cookie timeouts.
Summary logouts due to imp_key cookie timeouts.
Queue Horde Framework Packages
Queue Version HEAD
Type Bug
State Resolved
Priority 1. Low
Owners Horde Developers (at)
Requester mike.ryan (at) tufts (dot) edu
Created 2006-02-02 (4797 days ago)
Due
Updated 2006-03-05 (4766 days ago)
Assigned 2006-03-02 (4769 days ago)
Resolved 2006-03-05 (4766 days ago)
Milestone
Patch No

History
2006-03-05 21:54:08 Michael Slusarz Comment #9
State ⇒ Resolved
Reply to this comment
OK - Closing this key then as the 2nd patch looks to be unneeded.
2006-03-02 22:08:07 mike (dot) ryan (at) tufts (dot) edu Comment #8 Reply to this comment

[Show Quoted Text - 16 lines]
i think the second patch is unnecessary, yes.  i'd thought we were 
still running into cases where cookies were disappearing even with the 
first patch in place, but it was very rare, and i was never able to 
understand what could have caused it, particularly since the problem 
seemed to affect only the *_key cookies (and not Horde cookies).



our environment was pretty dynamic at the time -- we were juggling 
different versions and configurations of php and several different 
debugging patches to horde/imp at the same time.  i'm content to say i 
probably wasn't seeing what i thought i was seeing.
2006-03-02 05:27:03 Michael Slusarz Comment #7
State ⇒ Feedback
Priority ⇒ 1. Low
Reply to this comment
Knocking down as we are waiting for feedback on the IMP specific code.
2006-03-02 05:26:27 Michael Slusarz Comment #6 Reply to this comment
I've implemented some code (currently only in HEAD) to deal with this
- the code has been cleaned up somewhat from what you submitted.
After running this for a few days, this seems to work fine here so 
I've backported to F_3.


2006-02-28 18:18:12 Michael Slusarz Comment #5 Reply to this comment
another patch to make imp authentication more resilient against
disappearing cookies, due to timeouts or browser "quirks".  this will
recover the password from the horde credentials if possible, or
invalidate the session if the horde credentials can't be decrypted.
this gives the user a session error instead of a login error, which
may be less alarming, and prevents the failed IMAP login, which takes
time (10 to 15 seconds in our case) and leaves ugly log entries both
on the horde/imp server and the imap server.
Shouldn't this be fixed with the other commit referenced in this 
ticket?  the cookies - auth and app specific - are set within 
microseconds of each other, but cookie expiration are only allowed in 
seconds so this expiration value should be at most no more than a 
second different from each other.



this code is also invalid if not using 'hordeauth'.
2006-02-28 18:14:27 Michael Slusarz Comment #4 Reply to this comment

[Show Quoted Text - 15 lines]
I've implemented some code (currently only in HEAD) to deal with this 
- the code has been cleaned up somewhat from what you submitted.  See: 
http://lists.horde.org/archives/cvs/Week-of-Mon-20060227/055354.html



Could you see if this works for you?
2006-02-28 18:06:18 Michael Slusarz Comment #3
Priority ⇒ 3. High
Version ⇒ HEAD
Reply to this comment
Bumping.
2006-02-02 10:59:34 Jan Schneider Assigned to Horde DevelopersHorde Developers
State ⇒ Assigned
 
2006-02-02 03:34:14 mike (dot) ryan (at) tufts (dot) edu Comment #2
New Attachment: imp.patch Download
Reply to this comment
another patch to make imp authentication more resilient against 
disappearing cookies, due to timeouts or browser "quirks".  this will 
recover the password from the horde credentials if possible, or 
invalidate the session if the horde credentials can't be decrypted.   
this gives the user a session error instead of a login error, which 
may be less alarming, and prevents the failed IMAP login, which takes 
time (10 to 15 seconds in our case) and leaves ugly log entries both 
on the horde/imp server and the imap server.



i'm really not sure this is a good idea, but again, it seems to work for me.
2006-02-02 03:14:35 mike (dot) ryan (at) tufts (dot) edu Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ logouts due to imp_key cookie timeouts.
Queue ⇒ Horde Framework Packages
New Attachment: horde.patch Download
Reply to this comment
we're using horde 3.0.5, imp 4.0.4, turba 2.0.4, and ingo 1.0.2 for 
webmail, and running into a variety of cases where users are logged 
out prematurely.



we've tracked one of these cases to imp_key cookies timing out before 
the Horde session cookie.  when this happens, decryption of 
$_SESSION['imp']['pass'] results in garbage, IMAP login fails, and the 
user gets punted back to the login screen with a "Login failed" error. 
  we also get some interesting log entries (appended below).



one obvious reason why this can happen is that the imp_key cookie is 
set on the login screen, but the Horde cookie is reset (in 
lib/Horde.php) after login.  if the browser sits at the login screen 
for a while (e.g. machines in a lab), the imp_key and Horde cookie 
expirations may get quite out of sync.



the attached patch extends all *_key cookies when the Horde cookie 
gets reset if $conf['session']['timeout'] is non-zero.  this may not 
be the best solution, but it seems to work for me.



Jan 31 15:59:10 pitchblende.usg.tufts.edu HORDE[21748]: [ID 800047 
local4.error] [imp] FAILED LOGIN 130.64.202.238 to 
imap.tufts.edu:993[imap/ssl] as mryan01 [on line 237 of 
"/usr/local/apache/htdocs/horde/imp/lib/Auth/imp.php"]

Jan 31 15:59:10 pitchblende.usg.tufts.edu 
ZZZZZZ*\217<CC>\204\204\204ZZZZ[21748]: [ID 800047 local4.notice] PHP 
Notice:  (null)(): Authentication failed (errflg=1) in Unknown on line 0

Jan 31 15:59:10 pitchblende.usg.tufts.edu last message repeated 2 times

Jan 31 15:59:10 pitchblende.usg.tufts.edu 
ZZZZZZ*\217<CC>\204\204\204ZZZZ[21748]: [ID 800047 local4.notice] PHP 
Notice:  (null)(): Too many login failures (errflg=2) in Unknown on 
line 0

Saved Queries