httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: Change in how to configure authorization
Date Fri, 17 Feb 2006 18:23:45 GMT
>>> On 2/17/2006 at 10:38:17 am, in message
<20060217173816.GC21071@redhat.com>,
jorton@redhat.com wrote:
> On Tue, Feb 14, 2006 at 11:11:22AM -0700, Brad Nicholes wrote:
>> >>> On 2/14/2006 at 3:50 am, in message
>> <20060214105052.GA30079@redhat.com>,
>> jorton@redhat.com wrote:
>> > On Mon, Feb 13, 2006 at 03:42:27PM -0700, Brad Nicholes wrote:
>> >> 
>> >> 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
>> 
>> This is where I am a little confused.  The AUTH_GENERAL_ERROR is
coming
>> from the authn side not authz and nothing has really changed in
authn
>> between 2.2 and 2.3.  So I don't understand how it worked in 2.2. 
>> Looking at the code again, I think you are still going to need the
>> authany_handler() to handle the authentication.  If mod_auth_basic
tries
>> to handle the authentication, then it will attempt to default to
'file'
>> and fail as I mentioned before.  In fact, everything that was
working
>> before should continue to work correctly.  There is nothing to
prevent a
>> module from grabbing the same check_user_id and auth_checker hooks
and
>> handling them.
> 
> Sorry, everything I wrote above is wrong, not sure what I was smoking

> that day...
> 
> mod_authany with 2.2 and earlier was checking for the configuration 
> "Require user any-user" and then allowing authz if *any* basic auth 
> credentials had been sent in the request.  With the trunk code, since

> the check_user_id hook can no longer get to the requirements array 
> (ap_requires() has gone), it can't do this any more.  This is the 
> problem I was trying to work around and failing...
> 
> jo

So that's all OK and you can implement the authorization provider to
check that, but from what I can see you still need to register for the
authentication hook and hook it first as was being done previously.  If
you don't and you allow mod_auth_basic to handle the authentication, it
will default to the 'file' provider which will fail with a
AUTH_GENERAL_ERROR.  My point being that in your update to the 2.3 code,
you went too far by taking out the ap_hook_check_user_id() hook.  As far
as the authorization provider goes, the only reason for looping through
the ap_requires() elts was because all of the 'require' methods where
lumped together which required you to sift through them all to determine
if the one you were interested in is there.  With the provider based
implementation this is no longer necessary hence ap_requires() is no
longer necessary.  If you 'require user' then the 'user' provider is
what gets called.  So in the mod_authany case, you can create an
'any-user' provider and if it gets called, then it returns GRANTED. 
Which is exactly what 'valid-user' is doing so why not just use
'valid-user'?  Bottom line is that mod_auth_any just got smaller.  All
you really need is the authentication hook to intercept the
check_user_id call.  Everything else can just be handled by the existing
stuff.

I would go in and try to rework this myself but I can't get the
framework to work at all on any version of Apache.  When I run the
Makefile.PL everything builds and starts just fine up until the
framework checks to see if Apache is alive.  At that point it just hangs
there and finally times out assuming that Apache never completely
started.  I can hit the httpd server from a browser and all looks good
but I don't know what the script is waiting for.

Brad

Mime
View raw message