Re: Escaping of binary characters

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

Mark Hammond wrote:
> 
> I don't actually have neat sample code - I'm observing this inside Zope.

Is this a publicly available Zope component like LDAPUserFolder?

> However, what happens is:
> 
> * We query for the attribute 'objectGUID'.  We get back a 16 byte string - a
> raw binary representation of the 128-bit GUID.  This part works fine - we
> get the binary value from LDAP correctly.

Just curious because I'm always interested to learn anything people are
doing via LDAP:

Do you store the objectGUID to reference the single entry later?

Does this reference has to survive renaming of the entry?
If no, why don't you use the DN of the entry for a base level search later?

> * Later, we call search_s with a filter string '(objectGUID={string})',
> after calling escape_filter_chars with the exact value as previously
> fetched.  The filter fails, but succeeds with my implementation of
> escape_filter_chars.

Is this code specific for Active Directory (seems so to me)? Or does
your code has to work with any LDAP server with a configurable unique
and DN-independent attribute similar to objectGUID (e.g. entryUUID comes
to mind for OpenLDAP 2.2+)?

IMHO searching with the exact objectGUID returns exactly one entry
anyway. Therefore you could also use the entry's DN and retrieve the
entry with a base level search.

Well, I still didn't get the point of why you need a octet string
objectGUID in a search filter.

> it should read:
> 
> if c < ' ' or c > '~' or c in "\\*()":
> 
> which includes some extra punctuation. As far as I can tell, that
> will leave all 'printable' characters alone and should leave things
> as readable (even if slightly different than) the current
> implementation

Hmm, if I got you right this still escapes NON-ASCII chars which
otherwise could be displayed as UTF-8 encoded Unicode chars.

I'm also afraid this significantly slows down this function which is
probably not a big deal in most applications.

Ciao, Michael.