On Mon, Aug 19, 2002 at 09:47:35AM +0100, Philip Hazel wrote:
> > Furthermore, a DN may appear within a URL (e.g. as the search base) in which
> > case it is subject to URL quoting, or it may appear as a USER parameter in
> > which case it isn't.
>
> I already have an item on my "bugs and infelicities" list to look at
> LDAP quoting, so the clear details you've given are very timely. It
> certainly looks as though I'm going to have to end up with two different
> quoting functions.
I think there are three separate cases:
1. a value inserted into an LDAP URL search filter
ldap:///dc=example,dc=com???(uid=${quote:$1})
=> ${quote:fred*smith} --> fred\2asmith --> fred%5C2asmith
2. a value inserted into an LDAP URL basedn
ldap:///cn=${quote:$1},dc=example,dc=com?.....
=> ${quote:fred,smith} --> fred\,smith --> fred%5C,smith
3. a value inserted into a USER= dn
USER=cn=${quote:$1},dc=example,dc=com PASS=$2 ldap:///...
=> ${quote:fred,smith} --> fred\,smith
IMO, case 1 should be the default for 'quote_ldap'. From what I have read,
it is considered Bad Form to hard-code rules which construct DNs from
attributes as in cases 2 and 3. If you want to construct a DN, you are
supposed to _search_ for an entry which matches your attribute criteria.
That doesn't stop people bypassing that rule though :-)
So I think quote_ldap_dn should be a separate function. I can think of some
tricks by which you can avoid having a third function; in particular, the
USER= parameter could perform URL-dequoting of its value before passing it
to the LDAP server. So quote_ldap_dn would DN-quote and URL-quote as in case
2 above, then USER= would remove the URL-quoting.
Another idea is to embed the USER= parameter in the URL itself, using the
'bindname' extension in RFC2255. However it's more work to parse this out,
and there isn't a standard 'bindpassword' extension defined as far as I
know, so it's not really any cleaner.
Now, case 3 has a problem if $1 contains embedded spaces. This could be
another argument for quote_ldap_dn performing URL quoting and USER=
performing dequoting.
#### If quote_ldap_dn does URL escaping ####
USER=cn=${quote_ldap_dn:$1},%20dc=example,%20dc=com
# I think that's safe
#### If quote_ldap_dn does _not_ do URL escaping ####
USER=cn=${quote_ldap_dn:$1},dc=example,dc=com
# Fails if $1 contains spaces
USER="cn=${quote_ldap_dn:$1}, dc=example, dc=com"
# I think that fails if $1 contains double-quotes or backslashes
USER=${quote:cn=${quote_ldap_dn:$1}, dc=example, dc=com}
# Not sure about that!
Finally, what quoting, if any, is needed for the PASS= parameter? Consider
passwords which contains spaces or double-quotes or backslashes. Is
PASS=${quote:$2} # exim's standard quote operator
the right thing to do?
Regards,
Brian.
