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 | 06/16/2009 (5861 days ago) |
Due | |
Updated | 01/28/2016 (3444 days ago) |
Assigned | 02/20/2011 (5247 days ago) |
Resolved | 01/28/2016 (3444 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
State ⇒ Resolved
admin or user credentials.
Assigned to
Taken from Michael Rubinsky
removing myself.
Assigned to Michael Rubinsky
State ⇒ Assigned
Version ⇒ Git master
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. :)
locally accessible version of everyone's preferences, even if the main
source for them is LDAP/IMSP?
we are attempting to connect as. So any further attempts at prefs
access - even if from the current user - are never even attempted.
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.
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.
State ⇒ Feedback
Patch ⇒ No
Milestone ⇒
Queue ⇒ Horde Base
Summary ⇒ Sort out LDAP preferences mess with user bindings
Type ⇒ Bug
Priority ⇒ 1. Low
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.