AuthLDAPCharsetConfig considered harmful

[Joe Orton <jo...@redhat.com>]

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:

a) imposing a defacto standard, and 
b) setting an false expectation that use of non-ASCII usernames will 
actually work with HTTP, and
c) not going to work in practice, as I just had a user complain.

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

Regards, Joe

Re: AuthLDAPCharsetConfig considered harmful

[Joe Orton <jo...@redhat.com>]

On Tue, Feb 10, 2009 at 09:52:43AM -0500, Eric Covener wrote:
> On Tue, Feb 10, 2009 at 8:45 AM, Joe Orton <jo...@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?

That's probably a better way to put it, yes.

> > 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.

OK, even worse choice of language there, including the spelling.  But 
that is the point: it's extrapolating from the behaviour of a couple of 
browsers, rather than following any RFC...

...
> 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.

... and hence leads to interop failure.

> 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.

I think it would be better to simply advise against use of non-ASCII 
usernames in the docs.

Regards, Joe

Re: AuthLDAPCharsetConfig considered harmful

[Eric Covener <co...@gmail.com>]

On Tue, Feb 10, 2009 at 8:45 AM, Joe Orton <jo...@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