httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: Change in how to configure authorization
Date Tue, 14 Feb 2006 10:50:52 GMT
On Mon, Feb 13, 2006 at 03:42:27PM -0700, Brad Nicholes wrote:
> >>> On 2/13/2006 at 8:39:41 am, in message
> <20060213153940.GA3212@redhat.com>,
> jorton@redhat.com wrote:
> > On Mon, Feb 13, 2006 at 08:26:39AM -0700, Brad Nicholes wrote:
> >> Yes, we do need to make this change.  With the provider based 
> >> rearchitecting of authentication in httpd 2.2, this left
> authorization 
> >> in an unpredictable state especially when using multiple
> authorization 
> >> types.  You were never quite sure which one was going to happen
> first 
> >> and had no way to order them or control them.  With that, there was
> 
> >> also a growing demand to be able to apply AND/OR logic to the way in
> 
> >> which authorization is applied.  So basically this change brings 
> >> authorization up to the same level of power and flexibility that 
> >> currently exists in httpd 2.2 for authentication.  Hence being new 
> >> functionality, there are bound to be bugs that need to be fixed, 
> >> especially with backwards compatibility.  So let's get the bugs 
> >> identified and fixed.
> > 
> > Could you have a look at making the test suite pass again, to that
> end?
> > 
> > I tried to port mod_authany (c-modules/authany/mod_authany.c) to the
> 
> > trunk authz API, but to no avail.  The tests which fail are:
> > 
> > t/http11/basicauth..........# Failed test 2 in t/http11/basicauth.t
> at 
> > line 24
> > FAILED test 2
> > 	Failed 1/3 tests, 66.67% okay
> > t/security/CVE-2004-0811....# Failed test 1 in 
> > t/security/CVE-2004-0811.t at line 14
> > # Failed test 2 in t/security/CVE-2004-0811.t at line 14 fail #2
> > # Failed test 3 in t/security/CVE-2004-0811.t at line 14 fail #3
> > # Failed test 4 in t/security/CVE-2004-0811.t at line 14 fail #4
> > FAILED tests 1-4
> > 
> > joe
> 
> The other problem that I see in the configuration is that the <Location
> /authany> defines an authtype and authname but no authentication
> provider.  This means that the authentication provider will default to
> 'file'.  But since there hasn't been a password file specified either,
> the result is an AUTH_GENERAL_ERROR.  This scenario would occur with
> either 2.2 or trunk.

mod_authany is supposed to key off the AuthName configured for the 
location - if it's equal to "authname" then it kicks in and does the 
dummy authz hack.  No argument that this is a weird hack, but this 
worked in 2.2 and earlier, is there any way it can do something similar 
without requiring a config file change?

joe

Mime
View raw message