[#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 (at)
Requester jan (at) horde (dot) org
Created 2009-06-16 (2838 days ago)
Updated 2016-01-28 (421 days ago)
Assigned 2011-02-20 (2224 days ago)
Resolved 2016-01-28 (421 days ago)
Patch No

2016-01-28 20:29:31 Jan Schneider Comment #8
State ⇒ Resolved
Reply to this comment
Not an issue anymore since we always bind as configured now, with 
admin or user credentials.
2012-10-18 05:19:24 Michael Rubinsky Comment #7
Assigned to Horde DevelopersHorde Developers
Taken from Michael Rubinsky
Reply to this comment
Don't know if this is still relevant, but LDAP is not my area so 
removing myself.
2011-02-20 01:47:43 Chuck Hagenbuch Comment #6
Assigned to Michael Rubinsky
State ⇒ Assigned
Version ⇒ Git master
Reply to this comment
Bringing this back up...
2009-06-16 22:21:33 Michael Rubinsky Comment #5 Reply to this comment
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. :)

2009-06-16 21:15:57 Chuck Hagenbuch Comment #4 Reply to this comment
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?
2009-06-16 16:58:50 Michael Rubinsky Comment #3 Reply to this comment
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.
2009-06-16 15:46:08 Michael Rubinsky Comment #2 Reply to this comment
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.

2009-06-16 13:37:05 Jan Schneider Comment #1
Type ⇒ Bug
State ⇒ Feedback
Priority ⇒ 1. Low
Summary ⇒ Sort out LDAP preferences mess with user bindings
Queue ⇒ Horde Base
Milestone ⇒
Patch ⇒ No
Reply to this comment
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.

Saved Queries