This would break any passwd imap driver if imp is not present.
However I get the idea. Imp probably needs to overload this if horde 
authentication is set to imp.

this bug is a feature so live with it! (or uninstall broken passwd like i did)

No, because this is just a hack.

Based on previous contributions I made this patch that seems to works. 
I hope will add to the stable version of Passwd H4.

Sending patch which works for me:

File: passwd/lib/Passwd.php
Function (at the end of file): resetCredentials
Code (i added 3 lines which starts by '$imp_imap'):

     static public function resetCredentials($old_password, $new_password)
     {
         if ($GLOBALS['registry']->getAuthCredential('password') == 
$old_password) {
             $GLOBALS['registry']->setAuthCredential('password', 
$new_password);

             $imp_imap = 
$GLOBALS['injector']->getInstance('IMP_Factory_Imap')->create();
             $imp_imap->ob = NULL;
             
$imp_imap->createImapObject($GLOBALS['registry']->getAuth(), 
$new_password, IMP_Auth::getAutoLoginServer());
         }
     }


Jan, what do you think ?

I started to digging deeper into this and i found out something 
interesting. When password is changed it is reseted in cache via 
resetCredentials function. This function is reseting password stored 
in memory (in session). Problem is that password from session is NEVER 
used for logging into IMAP server.

Login to IMAP is done via Horde_Imap_Client which takes login and 
password as argument (in $params) and these values are set ONLY in 
constructor (this is done by Horde/IMP in createImapObject function 
called in Auth.php). Problem is that IMAP object is initialized only 
ONCE per IMAP login in our installation - so, when password changes, 
it is correctly updated in session but gets NEVER updated in IMAP 
object. I was doing some debug logging inside Horde and Horde/IMP and 
it is really like this, constructor for Horde_Imap_Client is called 
only once per login, the IMAP object is probably serialized and cached 
somewhere.

Still having the same problems even after upgrade to Horde 4.0.12 
(from 4.0.11). Any hints how to debug it ? I really wish to provide 
more info but everyone is ignoring this :(

i also tried what 'adominguez' suggested but it didn' help. any hints 
how can i debug this ?

i have Horde 4.0.11 and it's not fixed

It's not fixed in Passwd, it's fixed in Horde_Core.

still NOT fixed in Passwd 4.0 stable

Changes have been made in Git for this ticket:

[jan] Fix resetting authentication credentials (Bug #10228).

  1 files changed, 2 insertions(+), 0 deletions(-)
http://git.horde.org/horde-git/-/commit/dec002ce3a0e768ad1a425f8e3773f79f43f8fdd

I can change the password just fine now with the credentials being 
updated just fine too. I tested both with IMP doing the authentication 
for Horde and Horde doing the authentication itself, and IMP using 
hordeauth => true.

I think it's a bug there, can you try what I just committed?

Changes have been made in Git for this ticket:

Make sure that $app is not null in setAuthCredential() too (Bug #10228).

  1 files changed, 4 insertions(+), 0 deletions(-)
http://git.horde.org/horde-git/-/commit/60c7d1fe1d8338c512cf02ceeb2bcd61b8e8e44e

Hi I'm using the passwd code too, and I got the same problem whit it . 
I found that that the problem is  inside the function resetCredentials 
on passwd/lib/Passwd.php, first because the call to 
setAuthCredential() to set the new password is made on wrong way, we 
have to change from:

$GLOBALS['registry']->setAuthCredential('password', $new_password);

  to:

$GLOBALS['registry']->setAuthCredential('password', $new_password, 
$GLOBALS['session']->get('horde', 'auth/credentials'));


That's because the third parameter (The app name) on function 
setAuthCredential is bad calculate on class Horde_Registry when it is 
not passed to if function (because is optional), but the same 
parameter  on function getAuthCredential is rigth calculated when it's 
missing, so it could be a bug on  setAuthCredential.

But it is not over, because the class IMP_Imap have the configuration 
to conect to the IMAP server where it save the user a password and we 
have to reset that configuration and pass the new password, so on 
function resetCredentials  we have to add:

$imp_imap = 
$GLOBALS['injector']->getInstance('IMP_Factory_Imap')->create(null, 
true);$imp_imap->ob=NULL;
$imp_imap->createImapObject($GLOBALS['registry']->getAuth('bare'), 
$new_password, IMP_Auth::getAutoLoginServer());


And that is it.

I made the code changes that Ralf suggested and confirmed with 
getAuthCredential() that imp now has the new password in its 
$credential array but it still does not work.

It looks like IMP is still trying to access the IMAP server with the 
original IMAP object it created when I logged in initially and isn't 
attempting to login again. I added some debugging messages to the code 
to see what was going on:

Jun 11 12:13:18 test1 HORDE: HORDE [passwd] passwd: resetCredentials 
[pid 1466 on line 109 of 
"/usr/local/www/apache22/horde/passwd/lib/Passwd.php"]
Jun 11 12:13:18 test1 HORDE: HORDE [passwd] __call method alerts, 
params Array  [pid 1466 on line 329 of 
"/usr/local/www/apache22/horde/imp/lib/Imap.php"]
Jun 11 12:13:18 test1 HORDE: HORDE [imp] __call method status, params 
Array  [pid 1466 on line 329 of 
"/usr/local/www/apache22/horde/imp/lib/Imap.php"]
Jun 11 12:13:33 test1 HORDE: HORDE [imp] IMAP server denied 
authentication. [pid 1466 on line 343 of 
"/usr/local/www/apache22/horde/imp/lib/Imap.php"]

After resetCredentials is called, IMP never tries to login or do an 
imap open again. I think its still using the original ImapObject. 
createImapObject() is never called after the first login. Could this 
be an IMP bug?

Paste from Mailing list:

I am using the passwd code from git which I downloaded on June 6. It 
works, but does not reset my credentials within Horde, so I have to 
log out and log back in. My system is setup such that Horde 
authenticates via Imp and Imp uses IMAP Authentication. When I change 
my password with passwd, it successfully changes the password but IMP 
keeps trying to authenticate with the old password.

Reply from Ralf Lang:

Hi Kareem, can you please file a bug report?
I am on a long weekend holiday and might forget,
but maybe you can patch it yourself.

What resetCredentials basically needs to do (but doesn't) is

  * look if the authentication backend is Horde_Auth_Application
  * If so, call
  $GLOBALS['registry']->setAuthCredential('password', $new_password, $appname);
after
  $GLOBALS['registry']->setAuthCredential('password', $new_password);