Fri, 10 Apr 2026 15:26:35 +0000 https://bugs.horde.org/ticket/8353 Sort out LDAP preferences mess with user bindings 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. Tue, 16 Jun 2009 13:37:05 +0000 https://bugs.horde.org/ticket/8353#t54603 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. Tue, 16 Jun 2009 15:46:08 +0000 https://bugs.horde.org/ticket/8353#t54611 > 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. Tue, 16 Jun 2009 16:58:50 +0000 https://bugs.horde.org/ticket/8353#t54614 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? Tue, 16 Jun 2009 21:15:57 +0000 https://bugs.horde.org/ticket/8353#t54617 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. :) Tue, 16 Jun 2009 22:21:33 +0000 https://bugs.horde.org/ticket/8353#t54618 Bringing this back up... Sun, 20 Feb 2011 01:47:43 +0000 https://bugs.horde.org/ticket/8353#t61857 Don't know if this is still relevant, but LDAP is not my area so removing myself. Thu, 18 Oct 2012 05:19:24 +0000 https://bugs.horde.org/ticket/8353#t73792 Not an issue anymore since we always bind as configured now, with admin or user credentials. Thu, 28 Jan 2016 20:29:31 +0000 https://bugs.horde.org/ticket/8353#t89740