[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Problem with NON-ASCII chars in DNs when using OpenLDAP 2.1.x libs (ITS#1923)
Kurt D. Zeilenga wrote:
> Thanks for the detailed information. This the same issue
> reported in ITS#1890.
>
> The ldap_explode_dn() returns string representations of RDNs which
> conform to the syntax detailed in RFC 2253. Both 2.0 and 2.1 version
> can and will produce strings which included escaped values. In a
> number of cases, escaping is required by the technical specification.
> 2.1, however, will actively escape values and/or escape values
> differently than presented in its input. While this is a change
> in behavior from 2.0, it is not expected to cause problems with
> any application which is designed to properly handle the RDN escaping
> (which 2.0 produces in certain cases). That is, any application which
> has a problem with the change likely has bugs in its design. This
> change will aggravate those bugs.
My misleading error report was due to ldap_search() returning
LDAP_NO_SUCH_OBJECT when passing a DN as search root based on the
output of ldap_explode_dn(). See this python-ldap trace log
(Python script attached):
*** _ldap.<built-in function is_ldap_url>
(('ldap://localhost:1389',),{})
=> result: 1
*** ldap.ldapobject.SimpleLDAPObject.initialize
(('ldap://localhost:1389',),{})
=> result: <LDAP>
*** _ldap.<built-in function explode_dn> (('cn=Michael
Str\xc3\xb6der+mail=michael@stroeder.com,ou=Testing,dc=stroeder,dc=com',
0),{})
=> result: ['cn=Michael Str\\C3\\B6der+mail=michael@stroeder.com',
'ou=Testing', 'dc=stroeder', 'dc=com']
*** ldap.ldapobject.SimpleLDAPObject.search (('cn=Michael
Str\\C3\\B6der+mail=michael@stroeder.com,ou=Testing,dc=stroeder,dc=com',
0, '(objectclass=*)', ['cn'], 0),{})
=> result: 1
*** ldap.ldapobject.SimpleLDAPObject.result ((1, 1, -1),{})
=> LDAPError: {'info': '', 'matched':
'ou=Testing,dc=stroeder,dc=com', 'desc': 'No such object'}
> We, however,
> don't believe the change impacts any properly designed application.
> That is, properly designed applications should expect that RDN
> strings may contain escaped values.
And how should the application handle them? I mostly treat DNs to
be opaque. But I'm eliminating spaces from DNs because it caused
problems with some LDAP servers.
E.g. web2ldap transforms
uid=michael, dc=stroeder, dc=com
to
uid=michael,dc=stroeder,dc=com
before passing it back into python-ldap which directly wraps
ldap_search() and ldap_result() etc.
> I note that any application which wants to get at the value portion
> of the AVAs within the RDNs of a DN, should consider using
> ldap_str2dn(3) and, conversely, ldap_dn2str(3) which provides
> significant control over generation of DN (and RDN and AVA) string
> representations.
I will dig into that.
Ciao, Michael.