httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Covener <cove...@gmail.com>
Subject Re: AuthLDAPCharsetConfig considered harmful
Date Tue, 10 Feb 2009 14:52:43 GMT
On Tue, Feb 10, 2009 at 8:45 AM, Joe Orton <jorton@redhat.com> wrote:
> The AuthLDAPCharsetConfig directive allows server admins to do charset
> conversion of the username passed in the HTTP auth headers.
>
> RFC 2617 does not specify use of encoding non-ASCII usernames in the
> {Proxy-},Authorization request headers; mod_authnz_ldap is guessing an
> encoding based on any Accept-Language header in the request.  Given that
> use of non-ASCII in HTTP authz is not specified by RFC, this is:

Isn't it encoding agnostic, with the exception of ascii control characters?

> a) imposing a defacto standard, and

I had assumed it was compiled from browser observation, which would
make it a little more reactionary than it's painted here.

> b) setting an false expectation that use of non-ASCII usernames will
> actually work with HTTP, and

I agree that this partial/fuzzy solution is costly in terms of support

> c) not going to work in practice, as I just had a user complain.

When I looked at it, I thought it minimally needed to know user-agent
details and possibly some heurisitc to double-check the
utf8-or-local-codepage guess.

For example my notes imply the current scheme would have trouble with
recent Opera releases, which favor utf-8 for the encoding of the basic
auth credentials.

>
> So it seems like a bad idea all round.  Am I missing anything?
>

IMO makes sense at the very least to call out that it's a heuristic
that shouldn't be relied upon.

Being influenced by e.g. BrowserMatch, or the presence of certain
sequences provided by the user would go a long way in at least helping
a savvy administrator accomodate the unpredictable incoming charset.

-- 
Eric Covener
covener@gmail.com

Mime
View raw message