Not an issue anymore since we always bind as configured now, with 
admin or user credentials.

Don't know if this is still relevant, but LDAP is not my area so 
removing myself.

Bringing this back up...

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



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

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?

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.

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.

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.