httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Bowsher <>
Subject Re: Suggest renaming mod_authz_host to mod_access_host (better: mod_access)
Date Fri, 25 Nov 2005 13:06:12 GMT
Hash: SHA1

William A. Rowe, Jr. wrote:
> Joshua Slive wrote:
>> Joost de Heer wrote:
>>>> access control:
>>>>   is this request permitted, based on where it is being made from
>>> In other words, is the host from which the request comes, authorised
>>> to make this request? Hence mod_authz_host.
>> I tend to agree that the new name is confusing.  It is theoretically
>> possible to have host authz integrated into our system ("Require host
>>", for example), but it isn't designed that way.  But the
>> new name seems to suggest that it is part of the same system.
> Perhaps the real issue is that Satisfy/Allow/Deny is the confusing part,
> and these should all be rolled into Require ?
> <ducks/>

Or even just roll Satisfy into Require. However, doing this properly
means developing a way to specify both the logical AND-ing and logical
OR-ing of multiple Require lines.

However, any major directive reorganization is too late for 2.2, so
please can we get the module renamed to something appropriate for the
role it plays in the 2.2 aaa architecture?

If the architecture is reworked for 2.4, so that the module moves to a
different logical place, it can be renamed again.

Also, I've developed a further objection to the current mod_authz_host
name: Given that it provides access control based on environment
variables too, the _host portion of its name is just as inappropriate as
the _authz bit.

In view of this, I think the proper thing to do is to go back to the 2.0
name, mod_access, for 2.2. Then, see how the aaa archictecture evolves
toward 2.4, and choose a new name if it is appropriate. If the
access_checker/auth_checker divide has been removed, something like
mod_authz_host_env would then be appropriate, but to rename the module
away from mod_access in 2.2, based on what _might_ happen for 2.4, seems
terribly counter-intuitive to me.

Version: GnuPG v1.4.1 (Cygwin)


View raw message