6.0.0-alpha14
▾
Tasks
New Task
Search
Photos
Wiki
▾
Tickets
New Ticket
Search
dev.horde.org
Toggle Alerts Log
Help
7/3/25
H
istory
A
ttachments
C
omment
W
atch
Download
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
N
ew Ticket
M
y Tickets
S
earch
Q
uery Builder
R
eports
Saved Queries
Open Bugs
Bugs waiting for Feedback
Open Bugs in Releases
Open Enhancements
Enhancements waiting for Feedback
Bugs with Patches
Enhancements with Patches
Release Showstoppers
Stalled Tickets
New Tickets
Horde 5 Showstoppers