RFC: 2.2 vs third-party 2.0 auth modules

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

Whilst 2.2 is, as advertised, source-compatible with 2.0 auth modules, 
the current implementation requires that any auth configuration using 
such modules is changed to add "AuthBasicAuthoritative off" otherwise 
mod_auth_basic will see "no provider configured -> use default file 
provider -> fails (since no AuthUserFile is configured) -> deny access".

(the failure mode for this is particularly ugly: after an upgrade, a 
previously-working configuration turns into a 500 error with a weird 
error message logged as ap_pcfg_openfile returns APR_EBADF when passed 
the NULL filename by mod_authn_file)

There are lots of 2.0-compatible auth modules out there, and upgrades 
which require admins to make changes to .htaccess files are not very 
attractive, so I think it's worth solving this problem if possible.

Solutions I can see:

- only have mod_auth_basic be authoritative if AuthBasicProvider is 
configured

- use some hack such that mod_auth_basic will DECLINE iff no provider is 
configured and mod_authn_file throws the AUTHN_GENERAL_ERROR.  (attached 
as proof of concept)

Any thoughts, better ideas?

joe

Re: RFC: 2.2 vs third-party 2.0 auth modules

[Brad Nicholes <BN...@novell.com>]

>>> On 2/6/2006 at 8:26:07 am, in message
<20...@redhat.com>,
jorton@redhat.com wrote:
> Whilst 2.2 is, as advertised, source-compatible with 2.0 auth
modules, 
> the current implementation requires that any auth configuration using

> such modules is changed to add "AuthBasicAuthoritative off" otherwise

> mod_auth_basic will see "no provider configured -> use default file 
> provider -> fails (since no AuthUserFile is configured) -> deny
access".
> 
> (the failure mode for this is particularly ugly: after an upgrade, a

> previously-working configuration turns into a 500 error with a weird

> error message logged as ap_pcfg_openfile returns APR_EBADF when
passed 
> the NULL filename by mod_authn_file)
> 
> There are lots of 2.0-compatible auth modules out there, and upgrades

> which require admins to make changes to .htaccess files are not very

> attractive, so I think it's worth solving this problem if possible.
> 
> Solutions I can see:
> 
> - only have mod_auth_basic be authoritative if AuthBasicProvider is 
> configured
> 
> - use some hack such that mod_auth_basic will DECLINE iff no provider
is 
> configured and mod_authn_file throws the AUTHN_GENERAL_ERROR. 
(attached 
> as proof of concept)
> 
> Any thoughts, better ideas?
> 
> jo

Although the first solution would be cleaner, it would cause a change
in behavior when mod_auth_basic legitimately defaults to the file
provider.  So your second solution would probably be the best.  Of
course this would only happen if mod_auth_basic is loaded.  If it isn't
needed and loaded, the third party modules should work fine.

Brad