Is this fixed with #13283?

Changes have been made in Git (master):

commit 419159e52561a0399d7af05f1e17ab5c75aca5fc
Author: Thomas Jarosch <thomas.jarosch@intra2net.com>
Date:   Mon Jun 23 15:18:05 2014 +0200

     Horde_Secret: Fix up cookie key name on key change / unset

     This was introduced by commit

     00191e044206f496ae1f9084deed33d6c7919265

     [mms] If secret key is changed, change the associated $_COOKIE key
     or else key change may not be recognized in the current page 
access (Bug #11570).

     Signed-off-by: Michael M Slusarz <slusarz@horde.org>

  framework/Secret/lib/Horde/Secret.php |    4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

http://github.com/horde/horde/commit/419159e52561a0399d7af05f1e17ab5c75aca5fc

that old problem might be related to the fix for #13283

Ping?

I'm also seeing this now - but only with IE8.
In Firefox everything runs smoothly.

I try to dive into it...

It is reproducible, but only for me, so I'm going to release and try 
to track this down later.

Ping?  If this is happening, and is reproducible, it should be 
blocking on Horde 5.

Changes have been made in Git (develop):

commit 00191e044206f496ae1f9084deed33d6c7919265
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Wed Oct 24 13:43:13 2012 -0600

     [mms] If secret key is changed, change the associated $_COOKIE 
key or else key change may not be recognized in the current page 
access (Bug #11570).

     Conflicts:
             framework/Secret/package.xml

  framework/Secret/lib/Horde/Secret.php |    7 ++++++-
  framework/Secret/package.xml          |   13 +++++++++++++
  2 files changed, 19 insertions(+), 1 deletions(-)

http://git.horde.org/horde-git/-/commit/00191e044206f496ae1f9084deed33d6c7919265

Reverting this breaks things for me again.
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.)

FWIW, this sounds like the same issue that is some have reported with 
ActiveSync sessions getting cut short. Tracing the code shows that 
initial authentication is OK but at some point, accessing the IMP API 
fails authentication check.

No, that's not the issue. It's definitely commit 
00191e044206f496ae1f9084deed33d6c7919265 that's causing this. 
Reverting this instantly fixes the issue. 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.

May be clearing all cookies in the browser helps. I sometimes had 
problems switching from cookie based sessions to cookie less. Just a 
guess though ;)

Hm, since this change, I can't login anymore at all with cookie-less 
sessions. Well, I can login, but the credentials seem to get lost, 
because with any follow-up Kolab request I get a "Mail server denied 
authentication."

Thank goodness this is fixed. I was worried it might be something nasty ;)

This should fix.

Changes have been made in Git (master):

commit 00191e044206f496ae1f9084deed33d6c7919265
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Wed Oct 24 13:43:13 2012 -0600

     [mms] If secret key is changed, change the associated $_COOKIE 
key or else key change may not be recognized in the current page 
access (Bug #11570).

     Conflicts:
             framework/Secret/package.xml

  framework/Secret/lib/Horde/Secret.php |    7 ++++++-
  framework/Secret/package.xml          |   13 +++++++++++++
  2 files changed, 19 insertions(+), 1 deletions(-)

http://git.horde.org/horde-git/-/commit/00191e044206f496ae1f9084deed33d6c7919265

Changes have been made in Git (FRAMEWORK_4):

commit fd32947516291ae9a6618bb8c9010dcc9c9c94a5
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Wed Oct 24 13:40:25 2012 -0600

     [mms] If secret key is changed, change the associated $_COOKIE 
key or else key change may not be recognized in the current page 
access (Bug #11570).

  framework/Secret/lib/Horde/Secret.php |    7 ++++++-
  framework/Secret/package.xml          |    4 ++--
  2 files changed, 8 insertions(+), 3 deletions(-)

http://git.horde.org/horde-git/-/commit/fd32947516291ae9a6618bb8c9010dcc9c9c94a5

Hi,

when using sessions without cookies and having different IP addresses 
for the horde installation and the IMAP server, I cannot reuse the PHP 
session after a logout.

I've enabled the "debug" and "debug_raw" option in 
imp/config/backends.php so see what's going on.

This small tweak is applied to the code to log the IMAP password:
--- a/framework/Imap_Client/lib/Horde/Imap/Client/Socket.php
+++ b/framework/Imap_Client/lib/Horde/Imap/Client/Socket.php
@@ -610,7 +610,7 @@ class Horde_Imap_Client_Socket extends 
Horde_Imap_Client_Base
                  new 
Horde_Imap_Client_Data_Format_Astring($this->getParam('password'))
              ));
              $this->_sendLine($cmd, array(
-                'debug' => sprintf('[LOGIN Command - username: %s]', 
$this->_params['username'])
+                'debug' => sprintf('[LOGIN Command - username: %s, 
password: "%s"]', $this->_params['username'], 
$this->getParam('password'))
              ));
              break;


Some more info:
[root@intranator]# grep auth horde/config/conf.php
$conf['auth']['admins'] = array('admin');
$conf['auth']['checkip'] = true;
$conf['auth']['checkbrowser'] = true;
$conf['auth']['resetpassword'] = true;
$conf['auth']['alternate_login'] = false;
$conf['auth']['redirect_on_logout'] = false;
$conf['auth']['list_users'] = 'list';
$conf['auth']['params']['hostspec'] = '192.168.122.254';
$conf['auth']['params']['port'] = 143;
$conf['auth']['params']['secure'] = 'none';
$conf['auth']['driver'] = 'imap';
$conf['auth']['params']['count_bad_logins'] = false;
$conf['auth']['params']['login_block'] = false;
$conf['auth']['params']['login_block_count'] = 5;
$conf['auth']['params']['login_block_time'] = 5;



Analyzing at the IMAP debug output, I can see that 
"$this->getParam('password')" is empty when trying to reuse the 
session ID.

-> The login screen somehow fails to set the "new" password or some 
kind of other magic resets it. When using sessions with cookies, 
re-login works fine.


Cheers,
Thomas