We won't update in-session data, but instead provide means to log out 
automatically in Passwd.
But we still need an API after updating passwords, because in some 
places we encrypt preferences (that include other passwords) with the 
old password. After changing the main password, those are lost.

That's exactly what I proposed.  So I am confused.

Note that you can't separate the "authentication" of an application 
from its session data.  They are tied together.  In other words: in 
IMP you can't expect changing the password in the IMP object is all 
that is needed.  There may be other session data (i.e. data added to 
the session by the user via configuration/hooks) that are tied to that 
previous password.  So it's all or nothing when clearing an application.
I don't understand.  If you call clearAuth(), it will attempt to call 
IMP's 'logout' method as you described.  If it fails (which it will in 
this situation), this exception should be caught and ignored within 
clearAuth().

If you call clearAuthApp(), the calling code should be responsible for 
catching and ignoring the exception.

I like the idea of just resetting auth and forcing the app to reauth though.
I doubt this will work, at least for IMP.

After the password is changed in the backend, I cannot call clearAuth 
or clearAuthApp because it would run pushApp,   
IMP_Application::_authenticated and in turn 
IMP_Auth::authenticateCallback. This would use the old invalid 
credentials and result in the dreaded "IMP NOT ACTIVATED" message.

Any idea how to break that is welcome.

I've thought about this more and am questioning the need for an API to 
reset credentials at all.

Seems to me that the passwd application should have a configuration 
option to indicate whether a successful password change should trigger 
a reset of ALL currently authenticated horde applications, a list of 
Horde applications, or none.  The passwd code should then call 
Horde_Registry#clearAuth() (for the first) or 
Horde_Registry#clearAuthApp() (for the second), re-set the credentials 
in the session (Horde_Registry#setAuth()), and then rely on the normal 
application login procedure to reauthenticate to those applications, 
if needed.

Add an API in Horde_Registry_Application (Horde_Core) which changes 
auth credentials and tells apps to reauthenticate with the new 
credentials, ignoring cached sessions and credentials. This is needed 
for IMP and gollem in some scenarios.

cf Horde_Registry_Application#changeLanguage() for similar functionality.

michael slusarz said:

With our package structure, this is now something that can be added to 
the Core functionality without requiring a new major release.  If 
implemented via a Registry_Application call, this will bump the 
Registry API.  But it's not BC breaking, since you can update 
Horde_Core without updating applications and it won't break anything 
(it won't do anything either, but that's not relevant for this 
discussion).

It does make sense to implement in this matter.  Not a big deal if one 
of these more untested apps (passwd) requires something other than a 
x.0 install anyway; in other words, I'm suggesting that this sort of 
registry change is most appropriate to add to IMP 6.1.  There's still 
some limitations though: any user defined code in an init hook won't 
be triggered if the password changes.  *That* is something that can't 
really be addresses until the next major Horde release.

In other words - the best/cleanest solution is probably to instead 
require that if the password changes, the Horde session is destroyed.   
IMHO, this is not asking too much: password changes are fairly rare, 
it prevents all possible authentication problems, and this is not an 
alien concept to users since all sorts of websites require 
re-authentication when the password changes.

michael