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

* Your Email Address
* Spam protection	Enter the letters below: . __..__..__ .__. \| (__ \| \|[__)\| \| \|___.__)\|__\\| \|__\
Comment	>> 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.)
Attachment
Watch this ticket

Saved Queries