>>> On 5/2/2007 at 11:47 AM, in message <[EMAIL PROTECTED]>, "Joshua Slive" <[EMAIL PROTECTED]> wrote: > On 5/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> Author: bnicholes >> Date: Wed May 2 09:31:39 2007 >> New Revision: 534533 >> >> URL: http://svn.apache.org/viewvc?view=rev&rev=534533 >> Log: >> re-introduce ap_satisfies API back into core and modify how the > access_checker, check_user_id and auth_checker hooks are called so that they > respect the precedence that is set through the satisfy ALL/ANY directive. > This also restores the directives order, allow, deny, satisfyas supported > directives rather than being deprecated. These directives still remain in > mod_access_compat however. >> > > Fine. But then let's just revert mod_authz_host to the 2.2 version and > delete mod_access_compat. (Or, in other words, rename > mod_access_compat to mod_authz_host.) I don't see the reason for > having two supported ways of doing the same thing. > > Joshua.
Yeah, that's where I mentioned that things might look a little confusing. There actually is a good reason to have both and yes some of the functionality can overlap. The reason for having mod_authz_host is so that host, IP, ENV, etc. can be used during authorization as well. This really wasn't as issue in 2.2 because the AND/OR/NOT logic didn't exist yet. Now that you can apply this type of logic to authorization, allowing host, IP, ENV, etc. to be part of that, make sense. If we moved mod_authz_host back to the 2.2 version, in the first place it would no longer be authz but just mod_access again and you wouldn't be able to include host, IP, ENV, etc. as part of an authorization rule. But I agree that mod_access_compat name no longer makes sense. Brad
