[Date Prev][Date Next]
Re: Internal states o_dn and o_ndn are the same (ITS#2304)
On Fri, Feb 07, 2003 at 01:50:42PM +0000, Pierangelo Masarati wrote:
> > [Reason this is a problem for me: I have an LDAP backend which,
> > requires its bind DN to be case-sensitive. I can't validate the DN properly
> > back-foo/search.c if it has been uppercased.]
> I'm afraid yours is a poor assumption. I understand your point,
> but for many reasons you should not rely on c_dn being not normalized;
> since in many cases it may result from a sasl authc/authz id, it is
> likely to be normalized in any case.
OK. My workaround has been to set 'edn' in my backend bind function, since
this propagates to c_dn without being normalised.
The current behaviour just seems inconsistent, which is why I reported it as
a bug: either c_dn is supposed to hold a normalised DN (in which case it can
be copied directly to o_ndn and there is no need for o_dn at all), or c_dn
is supposed to hold the unnormalised DN (which it doesn't).
> I think you should work on removing
> this limitation from your backend. In case you plan to move your
> backend to 2.1 (which I stongly suggest) you'll find plenty of functions
> to handle your DNs.
I'll look at 2.1 at some point in the future. I know it's technically a
violation of the protocol, but the DN here needs to be case-sensitive
because it's being used to validate RADIUS and POP3 logins (which are also
dn: uid=FOObar, servgrp=pop3, dc=top # two different accounts
dn: uid=fooBAR, servgrp=pop3, dc=top
To follow the LDAP model properly I would have to allocate a unique ID which
was not related to the username:
("uid=FOObar") -> dn: uid=1234, servgrp=pop3, dc=top
("uid=fooBAR") -> dn: uid=9876, servgrp=pop3, dc=top
But this does not map well to the data model which my backend is having to
In any case, thank you for your prompt reply.