python-ldap-dev

Problems with function ldap.explode_dn()

[<OHU...@sp...>]

Hello,

since changing to python 2.3.2, OpenLDAP 2.1.23 and python-ldap-2.0.0pre15
I have problems with explode_dn(), related to diacritics; as You can see:

Python 2.3.2 (#1, Oct 26 2003, 16:43:30)
[GCC 3.3.1] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import ldap
>>> dn="uid=ascii,l=München_iso-8859-1"
>>> ldap.explode_dn(dn)
['uid=ascii']
>>> ldap.explode_dn(dn.decode('latin'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/site-packages/ldap/functions.py", line 84, in explode_dn
    return _ldap_function_call(_ldap.explode_dn,dn,notypes)
  File "/usr/local/lib/python2.3/site-packages/ldap/__init__.py", line 62, in _ldap_function_call
    result = apply(func,args,kwargs)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 13: ordinal not in range(128)
>>> ldap.explode_dn(dn.decode('latin').encode('utf'))
['uid=ascii', 'l=M\\C3\\BCnchen_iso-8859-1']
>>> vgl=ldap.explode_dn(dn.decode('latin').encode('utf'))[1]
>>> vgl
'l=M\\C3\\BCnchen_iso-8859-1'
>>> vgl=="l=München_iso-8859-1".decode('latin').encode('utf8')
False

In the last working versions, I didn't need to encode or decode the strings.

Beeing very RFC-strict I would have to use utf-8 encoding. But the result
also should be utf-8 encoded, which isn't the case. Any ideas?


Kind Regards
Eckard

Re: Problems with function ldap.explode_dn()

[<mi...@st...>]

OHU...@sp... wrote:
>=20
>>>>dn=3D"uid=3Dascii,l=3DM=FCnchen_iso-8859-1"
>>>>ldap.explode_dn(dn)
>=20
> ['uid=3Dascii']

Hmm, this looks wrong. Using ISO-8859-1 is wrong with LDAPv3 anyway.

>>>>ldap.explode_dn(dn.decode('latin'))
> [..]
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in pos=
ition 13: ordinal not in range(128)

Off course you can't encode the raw string. dn is supposed to be an Unico=
de=20
object.

>>>>ldap.explode_dn(dn.decode('latin').encode('utf'))
>=20
> ['uid=3Dascii', 'l=3DM\\C3\\BCnchen_iso-8859-1']

Now this shows that the underlying OpenLDAP function ldap_explode_dn() is=
=20
aware of DN strings having to be UTF-8 encoded Unicode.

Note that you SHOULD use 'utf-8' as unique ID for UTF-8.

>>>>vgl=3Dldap.explode_dn(dn.decode('latin').encode('utf'))[1]
>>>>vgl
>=20
> 'l=3DM\\C3\\BCnchen_iso-8859-1'
>=20
>>>>vgl=3D=3D"l=3DM=FCnchen_iso-8859-1".decode('latin').encode('utf8')
>=20
> False

The DN string normalization (with back slash representation) is done with=
in=20
the OpenLDAP libs. The behaviour changed from OpenLDAP 2.0 to 2.1. I alre=
ady=20
had a discussion with Kurt Z. about that. His argument was that LDAP=20
applications should treat DNs as being opaque. There's nothing we can do =

about it. This breaks things when accessing OpenLDAP 2.0 server since 2.0=
=20
did not implement correct matching rules for DNs. Oh yeah...

> Beeing very RFC-strict I would have to use utf-8 encoding. But the resu=
lt
> also should be utf-8 encoded, which isn't the case. Any ideas?

Input and output of ldap_explode_dn() both have to be a valid DN string=20
representation as of RFC2253 which is the case. Guess you have to live wi=
th=20
that.

Ciao, Michael.