[Tickets #11570] Re: Session without cookies: Re-login fails

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/11570
------------------------------------------------------------------------------
  Ticket             | 11570
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | Session without cookies: Re-login fails
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
-State              | Assigned
+State              | Feedback
  Priority           | 2. Medium
  Milestone          |
  Patch              |
-Owners             |
+Owners             | Horde Developers
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2012-10-26 14:34) wrote:

> No, that's not the issue. It's definitely commit  
> 00191e044206f496ae1f9084deed33d6c7919265 that's causing this.  
> Reverting this instantly fixes the issue.

Reverting this breaks things for me again.

> I also see this on non-Kolab setups where transparent authentication  
> to IMP after a successful login to Horde fails. It doesn't matter if  
> I use 'hordeauth' or application authentication.

I don't see this.  i.e. If I switch to imap authentication in Horde  
with transparent auth to IMP, things work fine.  I can login/logout  
all I want with no issues.

In Horde_Core_Secret, I changed the getKey() method to look like this:

     public function getKey($keyname = self::DEFAULT_KEY)
     {
         Horde::debug(parent::getKey(self::HORDE_KEYNAME), null, false);
         return parent::getKey(self::HORDE_KEYNAME);
     }

And watched the output of the Horde debug file after I logged in.   
Sure enough, every log entry is of the same secret key (as expected).   
Reverting 00191e044206f496ae1f9084deed33d6c7919265  I see the same  
thing for cookie sessions.

However, reverting 00191e044206f496ae1f9084deed33d6c7919265  for  
non-cookie based sessions indicates two different secret keys are used  
during the login, which is what that commit fixed (we would change the  
key but the subsequent call to get the secret key in IMP would use the  
original value, not the changed value, for the duration of that page  
access).

Someone who is seeing this behavior is going to have to find out  
where/why their secret key is changing.  Make sure your session is  
properly destroyed too when logging out.  (I have tested with both  
files and memcache and it works on both.)