6.0.0-git
2019-03-24

[#1801] first time imp authentication error with hordeauth
Summary first time imp authentication error with hordeauth
Queue Horde Base
Queue Version 3.0.4
Type Bug
State Resolved
Priority 2. Medium
Owners Horde Developers (at)
Requester amy.rich (at) tufts (dot) edu
Created 2005-04-15 (5091 days ago)
Due
Updated 2006-03-27 (4745 days ago)
Assigned 2005-04-16 (5090 days ago)
Resolved 2005-05-05 (5071 days ago)
Milestone
Patch No

History
2006-03-27 19:14:36 ben (at) smallercircle (dot) com Comment #14 Reply to this comment
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).


2005-11-04 03:50:09 card (at) scouthoster (dot) com Comment #13 Reply to this comment
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.
2005-08-29 18:55:31 gskinner (at) ycp (dot) edu Comment #12 Reply to this comment
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.
2005-07-13 14:23:03 amy (dot) rich (at) tufts (dot) edu Comment #11 Reply to this comment
We've been doing some minimal testing with 3.0.5-RC2, and this issue 
appears to be fixed now.


2005-05-16 04:14:03 Michael Slusarz Comment #10 Reply to this comment
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.
2005-05-07 04:01:19 Chuck Hagenbuch Comment #9 Reply to this comment
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.
2005-05-05 18:12:05 Chuck Hagenbuch Comment #8
State ⇒ Resolved
Reply to this comment
Duplicate of 1580, after analysis.
2005-05-05 00:29:40 amy (dot) rich (at) tufts (dot) edu Comment #7 Reply to this comment
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.
2005-05-04 18:42:09 Chuck Hagenbuch Comment #6 Reply to this comment
Possibly related to bug 1580?
2005-05-04 17:47:29 kevin_myer (at) iu13 (dot) org Comment #5 Reply to this comment
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...
2005-05-04 11:56:12 kevin_myer (at) iu13 (dot) org Comment #4 Reply to this comment
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...
2005-04-25 16:52:12 Jan Schneider Comment #3 Reply to this comment
You could try to track down where/why exactly this is happing. But be 
warned, this is hard to debug.
2005-04-25 14:01:05 kevin_myer (at) iu13 (dot) org Comment #2 Reply to this comment
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
2005-04-16 09:20:25 Jan Schneider State ⇒ Assigned
Assigned to Horde DevelopersHorde Developers
 
2005-04-15 14:43:21 amy (dot) rich (at) tufts (dot) edu Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Summary ⇒ first time imp authentication error with hordeauth
Queue ⇒ Horde Base
Reply to this comment
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.

Saved Queries