Sequence of events are as follows:
ldap_search_ext_s to an ldap URL and search base that does not contain
UTF-8 characters.
manager bindDn and bindPw do not contain UTF-8 charaters (all are
US-ASCII) only. The attribute being searched for (uid) does not contain
UTF-8 characters as well.
For example
ldap://server/cn=Name[UTF-8 character]MoreName, ou=people
-> uid=usasciiname (attribute)
The DN returned once Apache pulls it out from the ldap_search_ext_s
results is now cn=Name?MoreName, ou=people.
Basically the dn returned in the following two lines is already mangled
with the ? character:
entry = ldap_first_entry(ldc->ldap, res);
dn = ldap_get_dn(ldc->ldap, entry);
Thanks,
Andy
Eric Covener wrote:
On Wed, Jul 16, 2008 at 4:55 PM, Andy Wang <[EMAIL PROTECTED]> wrote:
the case where we're seeing this none of the arguments contain anything
other than US ASCII characters. If you're ldap_search_ext_sW call contains
only US-ASCII but the returned DN contains UTF-8 shouldn't this still work
or is there something I'm missing here?
Can you more concretely describe which LDAP call fails? The sequence
is roughly:
authn: Apache searches for a DN that corresponds to the basic auth username
authn: Apache binds with the retrieved DN and the basic auth password
authz: Apache may do searches with a base of the retrieved DN.
You previously implied the failure happened after we'd bind'ed with
the DN to check the users password, which would mean the failing call
does in fact have non US-ASCII characters (the DN). The only
US-ASCII-safe input in this workflow should be the initial search from
basic auth -> DN
If your LDAP data were somehow not the UTF-8 sequence you expected,
that might be the cause of the unexpected result.
