>>> On 2/17/2006 at 10:38:17 am, in message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > On Tue, Feb 14, 2006 at 11:11:22AM -0700, Brad Nicholes wrote: >> >>> On 2/14/2006 at 3:50 am, in message >> <[EMAIL PROTECTED]>, >> [EMAIL PROTECTED] 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
