[Tickets #11924] Re: Add API in Horde_Registry_Application to reset credentials

[noreply at bugs.horde.org]

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

Ticket URL: http://bugs.horde.org/ticket/11924
------------------------------------------------------------------------------
  Ticket             | 11924
  Updated By         | mooroon2 at mail.ru
  Summary            | Add API in Horde_Registry_Application to reset
                     | credentials
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Enhancement
  State              | Feedback
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2013-01-06 21:36) wrote:

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

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.

> 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.

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.