I'm not sure that ...ByLanguage is correct either. The AuthLDAPConvertFromLanguage
directive can take either a language identifier (es, de, fr, en, etc.) or a charset
(ISO-8859-xx, etc). The end result should be a character set ID that can be passed to
apr_xlate_open(). I am thinking that maybe the best name would be
"AuthLDAPCharsetConversion <from> <to>" where <from> would be the language or charset
that you are converting from and <to> would be the character set that you are
converting to (obviously). Since LDAP expects UTF8 encoding, if <to> is omitted then
the default would be UTF8 since it doesn't really make any sense to convert to
anything else. The <to> parameter is only available to allow the user to specify the
correct UTF8 string ID that corresponds to the platform's implementation of iconv()
(if that is even an issue???).
I thought about implementing the UTF8 conversion through an input filter, but I'm
not sure I want to take that task on yet. I am also not sure that the two issues are
related anyway. LDAP needs a specialized conversion. It only needs to have the user
name portion of the authentication string converted to UTF8. A filter would UTF8
encode everything which wouldn't necessarily be correct. I see some issues with it
anyway.
1. Why should all requests take the conversion hit if it isn't needed or wanted?
2. LDAP, at least the Novell LDAP SDK, can not deal with encoded passwords. The
password part of the
authentication header must not be UTF8 encoded.
3. How do you deal with decrypting->converting->encryption the authentication
header so that the conversion to UTF8 is
transparent to the rest of the code? Base64 may not be a problem, but what
about digest?
4. Other authentication modules do not expect UTF8 and would have to be retrofitted.
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
>>> [EMAIL PROTECTED] Friday, December 06, 2002 11:07:05 PM >>>
At 03:42 PM 12/6/2002, Brad Nicholes wrote:
> This patch adds a new directive "AuthLDAPConvertFromLanguage" to mod_auth_ldap
>that allows the admin to either define a specific language when converting the user
>ID to UTF8 of try to derive the language from the header.
Ewww... charsets aren't languages. '...ByLanguage' would be more appropriate.
More to the point... all headers suffer from this problem. If we are going to
address dealing with non-utf-8 headers into a canonical utf-8 form, I'd prefer
some directive to deal with this across the board. Win32 would actually
prefer to deal in utf-8 identifiers, and if we invest the energy in 'fixups' for
one canonical header (user/passwords) then we aught to think about dealing
with them all in one place.
And that place wouldn't be in ldap, but more likely in a module like
mod_charset_headers or something that will just deal with all of the
implications of HTTP/1.1's inbound 'opaque' high-bit characters; perhaps
we fix outbound header fields as well.
Just my (selfish) 2c :)
Bill
p.s. honest - hadn't even read on to Andre's response when I wrote
the response above, but +1 to his observations :)
