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

* Your Email Address
* Spam protection	Enter the letters below: .__..__ .__ . .. . [__][__)[ __\|_/ \| \| \| \|[__)[_./\| \\|__\|
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 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. > >
Attachment
Watch this ticket

Saved Queries