[Tickets #8353] Re: Sort out LDAP preferences mess with user bindings

[bugs at horde.org]

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

Ticket URL: http://bugs.horde.org/ticket/8353
------------------------------------------------------------------------------
  Ticket             | 8353
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | Sort out LDAP preferences mess with user bindings
  Queue              | Horde Base
  Version            | 3.3.4
  Type               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2009-06-16 11:46) wrote:

My .02:

FWIW, this is not an issue completely specific to LDAP.  It's an issue  
with any existing or future prefs backend that requires an explicit  
user login. LDAP is one, IMSP is another. Granted, IMSP is a really  
bad choice for a prefs backend for a variety of reasons, not the least  
of which is that it is *impossible* to access another user's prefs via  
the IMSP server without logging in as that user, but we have a driver  
for it so it needs to be considered as well - unless we deprecate it.

Most of the patches in the other tickets focus on making sure we pass  
the user's current Horde password ( as returned by  
Auth::getCredential('password')).  While this makes sense in the cases  
where we are 100% sure we are fetching prefs for the current user,  
this doesn't help one bit in other cases. As an aside - is it safe to  
assume that a user's Horde credentials will be the user's LDAP  
credentials?

The bigger issue, IMO, is how the failure is handled in Prefs:: -  
right now, we call $notification->push() directly from  
Prefs_*::_retrieve() and remember the failure regardless of the user  
we are attempting to connect as. So any further attempts at prefs  
access - even if from the current user - are never even attempted.   
So, the question is how to fix this in a BC way.

Ideally, we shouldn't push a notification when failing for a user  
other then the current and make sure out applications are tolerant to  
not having access to other users' prefs - but doing this in a BC way  
by comparing Prefs::_user with Auth::getAuth() is a bit hackish. Even  
if we don't ignore the failure we need to change how we remember the  
failure in the session - something like  
$_SESSION['prefs_cache']['unavailable'][$username_hash] instead of  
just $_SESSION['prefs_cache']['unavailable'] so that any subsequent  
prefs access will not fail for the current user.