[#8353] Sort out LDAP preferences mess with user bindings
Summary Sort out LDAP preferences mess with user bindings
Queue Horde Base
Queue Version Git master
Type Bug
State Resolved
Priority 1. Low
Owners Horde Developers
Requester jan@horde.org
Created 2009-06-16 (4232 days ago)
Updated 2016-01-28 (1815 days ago)
Assigned 2011-02-20 (3618 days ago)
Resolved 2016-01-28 (1815 days ago)
Patch No

Jan Schneider <jan@horde.org> 2009-06-16 13:37:05
If the LDAP preferences have been configured to bind with the user's 
credentials, we can't retrieve other users' preference, e.g. to 
display their full names etc. This problem manifests at many different 
points, this ticket is supposed to help finding a general solution.

Possible problems, discussions, and patches can be found in the 
tickets #7418, #8246, #8270, #8271, #8251, #8269.

It would be great if someone taking part in those discussions could 
summarize them and show the possible solutions.

Michael Rubinsky <mrubinsk@horde.org> 2009-06-16 15:46:08
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 

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.

Michael Rubinsky <mrubinsk@horde.org> 2009-06-16 16:58:50

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

Looking further, I misread the code in that method dealing with 
remembering the errror. We only check the session for a previous error 
if _connect returns an error - so this specific part isn't an issue in 
this case.  It would only be an issue in that it could hide a later, 
unrelated error...a very fringe case I would think.  I still think 
comparing Prefs::_user and Auth::getAuth() before pushing the 
notification would be a reasonable way to go here though.

Chuck Hagenbuch <chuck@horde.org> 2009-06-16 21:15:57
Longer term - i.e., not for 3.3.x - do we want to consider having a 
locally accessible version of everyone's preferences, even if the main 
source for them is LDAP/IMSP?

Michael Rubinsky <mrubinsk@horde.org> 2009-06-16 22:21:33
That's an interesting thought.  My first reaction would be that 
depending on how the local version of the data is stored, it might 
defeat the purpose of not using a SQL database to store it to begin 

On the other hand, if you want the functionality, you have to pay the 
price. :)

Chuck Hagenbuch <chuck@horde.org> 2011-02-20 01:47:43
Bringing this back up...

Michael Rubinsky <mrubinsk@horde.org> 2012-10-18 05:19:24
Don't know if this is still relevant, but LDAP is not my area so 
removing myself.

Jan Schneider <jan@horde.org> 2016-01-28 20:29:31
Not an issue anymore since we always bind as configured now, with 
admin or user credentials.