This issue is not resolved, and I'm still seeing it with the latest 
stable versions of Horde and IMP.



The initial comment describing this issue describes the issue that I'm 
seeing perfectly.



I've been able to trace the problem to line 86 of imp/lib/IMAP.php. 
The line is:

$this->_pass = Secret::read(Secret::getKey('imp'), $_SESSION['imp']['pass']);



During the initial login, $this->_pass is set to a non-sensical string 
(and varies).

I am also running 3.0.5 and still having this problem, exactly as 
described below. I can provide an email login if necessary for 
verification.

I'm running 3.0.5 official release and I am experiencing the initial 
login problems that this ticket deals with.  Has this issue truly been 
resolved.



Greg

We've been doing some minimal testing with 3.0.5-RC2, and this issue 
appears to be fixed now.

For reasons touched on here:

http://lists.horde.org/archives/dev/Week-of-Mon-20050509/017803.html

The read-only patches Chuck mentions are not a solution to this issue.

Does not fix the underlying issue, but may help:



http://lists.horde.org/archives/cvs/Week-of-Mon-20050502/044320.html



Try the two patches (to sidebar.php and base.php) - they make the 
sidebar use readonly sessions.

Duplicate of 1580, after analysis.

I went back and checked to see if we had the error when using the PHP 
file preference back end instead of mysql.  Similar to Kevin, 
everything seems to work fine if we use files instead of mysql.   
That's not really an option for us, though, since we have loadbalanced 
webservers.

Possibly related to bug 1580?

Another interesting thing I found is that if you use php file-based 
sessions, hordeauth with IMP works great.  If you use MySQL based 
sessions, the login fails the second time you attempt to access 
anything mail related...

Here's some additional information I've found with this:



For us, its either a first-time or second-time authentication error 
with IMP.  One install, with IMP setup as the initial application, 
displays my INBOX the first time, but I get an authentication error 
when I click on a message to read it.  Another install immediately 
throws me into a redirect loop.



If I stop the redirect loop, and have a mail summary block in my 
portal view, I'm able to login successfully in the second looping 
scenario.



I've captured some packets in the first scenario, which seems to be 
reproducible for the first login attempt, per browser session (i.e. if 
I quit the browser and restart it, the first attempt to access a 
message after logging in will fail.  If I just logout and back in, I 
don't have the problem).  The username and password that is being 
passed on the failed login is:  kevin_myer {8}.



We're using IU13 for $conf['session']['name'].



For a failed login, the value of the cookie set for IU13 == the value 
set for imp_key, and auth_key is different (this seems to be true for 
all failed logins).  Sometimes for a successful login, IU13 != 
auth_key != imp_key.  But sometimes, I think auth_key == imp_key too.



imp_key remains the same, even after a logout.



Should the cookie values be getting cleared after a successful logout 
or only after the browser is closed?



Going to see if I can figure out what different code path the mail 
summary block takes for authentication, versus a traditional display 
the INBOX and click on a message authentication...

You could try to track down where/why exactly this is happing. But be 
warned, this is hard to debug.

Jan,



Anything I can do to help track down the cause of this?  We're seeing 
it on a regular basis and I'd like to help get a fix into place.



Thanks,

Kevin

When using hordeauth to authenticate for imp, the first login fails.   
The user is logged into horde but recieves a login error from IMP.   
This appears to be related to the existance of cookies in the client's 
browser.  As long as the imp_key cookie is not deleted, subsequent 
logins work fine.  If the imp_key cookie is removed, the same 
behaviour as a first time login is experienced.



Interestingly, and possibly related, if one deletes the Horde cookie 
without deleting the auth_key cookie, the server loops on trying to 
log in.  If the Horde and auth_key cookies are deleted but the imp_key 
cookie left alone, things work fine.