[Tickets #11766] Re: [passwd] imp is not activated.

[bugs at horde.org]

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

Ticket URL: http://bugs.horde.org/ticket/11766
------------------------------------------------------------------------------
  Ticket             | 11766
  Updated By         | Ralf Lang (B1 Systems GmbH) <lang at b1-systems.de>
  Summary            | [passwd] imp is not activated.
  Queue              | Passwd
  Version            | Git develop
  Type               | Bug
-State              | Unconfirmed
+State              | Assigned
  Priority           | 2. Medium
  Milestone          |
  Patch              |
-Owners             |
+Owners             | Horde Developers, Ralf Lang (B1 Systems GmbH)
------------------------------------------------------------------------------


Ralf Lang (B1 Systems GmbH) <lang at b1-systems.de> (2012-12-03 07:36) wrote:

Well, I can reproduce it.

What basically happens is this:
When Horde uses imp as authentication and password is changed by  
passwd, for example via postfix admin database table, it also resets  
the session. It does not (and cannot easily) reset the internally  
stored imap connection.

I'm still resolving what happens afterwards.

I tried to add explicit re-authentication to passwd and additional  
code to IMP_Auth which would destroy/reopen an imap connection if  
parameter credentials do not match the IMAP ->ob credentials.

It does not get there though.

Somewhere in the stack between Horde's Auth_Application instance and  
imp's auth_application instance (_base) it already tries to access the  
imap object (probably part of application startup for an already  
authenticated scenario) before it can run IMP_Auth->authenticate. I'm  
still tracing where this happens, but any suggestions are welcome.