On Fri, Jul 14, 2017 at 11:04 PM, Magnus Hagander <magnus@hagander.net> wrote: > On Thu, Jul 13, 2017 at 9:31 AM, Thomas Munro > <thomas.munro@enterprisedb.com> wrote: >> A post on planet.postgresql.org today reminded me that a colleague had >> asked me to post this POC patch here for discussion. It allows custom >> filters with ldapsearchprefix and ldapsearchsuffix. Another approach >> might be to take a filter pattern with "%USERNAME%" or whatever in it. >> There's an existing precedent for the prefix and suffix approach, but >> on the other hand a pattern approach would allow filters where the >> username is inserted more than once. > > > Do we even need prefix/suffix? If we just make it "ldapsearchpattern", then > you could have something like: > > ldapsearchattribute="uid" > ldapsearchfilter="|(memberof=cn=Paris DBA Team)(memberof=cn=Tokyo DBA Team)" > > We could then always to substitution of the kind: > (&(attr=<uid>)(<filter>)) > > which would in this case give: > (&(uid=mha)(|(memberof=cn=Paris DBA Team)(memberof=cn=Tokyo DBA Team))) > > > Basically we'd always AND together the username lookup with the additional > filter.
Ok, so we have 3 ideas put forward:
1. Wrap username with ldapsearchprefix ldapsearchsuffix to build filter (as implemented by POC patch) 2. Optionally AND ldapsearchfilter with the existing ldapsearchattribute-based filter (Magnus's proposal) 3. Pattern-based ldapsearchfilter so that %USER% is replaced with username (my other suggestion)
The main argument for approach 1 is that it follows the style of the bind-only mode.
Agreed, but I'm not sure it's a good style to follow (and yes, I think I may be the original author of it..). I'd rank option 3 over option 1.
With idea 2, I wonder if there are some more general kinds of things that people might want to do that that wouldn't be possible because it has to include (attribute=user)... perhaps something involving a substring or other transformation functions (but I'm no LDAP expert, that may not make sense).
Yeah, that's exactly what I'm wondering about it :)
With idea 3 it would allow "(|(foo=%USER%)(bar=%USER%))", though I don't know if any such multiple-mention filters would ever make sense in a sane LDAP configuration.
Any other views from LDAP-users?
+1 for some input from people who directly use it in larger LDAP environments. If we're going to change how it works, let's make it right this time!