OK - Closing this key then as the 2nd patch looks to be unneeded.

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.

Knocking down as we are waiting for feedback on the IMP specific code.

After running this for a few days, this seems to work fine here so 
I've backported to F_3.

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'.

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?

Bumping.

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.

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