httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <>
Subject Re: Merging branch authz-dev - Authorization and Access Control 2.3 vs. 2.2
Date Wed, 11 Jan 2006 15:52:22 GMT
Joshua Slive wrote:
> [Your merge today prompted me to dig out a response I started but
> never finished.]
> I am still worried that we are underestimating the pain that this will
> cause.  In my opinion, a config change that requires substantial
> changes to every httpd.conf and many .htaccess files requires a major
> version bump (to 3.0) unless it can, in some way, be made seamless to
> the end user.  And there is no way to deny that this will put a large
> roadblock in the way of upgraders.

I would personally prefer spending a little time and adding some code to 
  handle the old configurations with the new code.  Maybe spit out some 
warnings to the log, but hard breaks in the config suck.  Authn did it 
for more complicated handlers like ldap, but the basic file 
configuration worked without modification.


> On 1/6/06, Brad Nicholes <> wrote:
>>    I believe that this could probably be done.  Basically "Allow from"
>> was split into the 'IP', 'Host', etc. providers because that is how it
>> was represented in the source code and it just naturally fell out that
>> way.
> From a code perspective, I understand.  But the directives should be
> structured from a user perspective as much as possible.  I'd prefer to
> see just the "host".
>>   Honestly, I struggled with this naming myself but really couldn't
>> come up with anything better that would accurately represent "Allow from
>> all" or "Deny from all" and still fit the authz provider model.  I'm not
>> sure that  "Require host all"/"Reject host all" quite fits it either
>> because we aren't always talking about a host.
> But using host maps very well to how people currently think about
> this.  Host is the base access control method and other things are
> generally built on top.  Again, I'd prefer to see this folded back
> into host.
>>> 4. It isn't made clear anywhere whether RequireAll or RequireOne is
>> the
>>> default.
>>   Yeah it probably needs to be stated somewhere,  however the default
>> is <RequireOne> basically because that is how it works today if you use
>> multiple Require directives.  I guess I kind of expected that to be
>> obvious.
> Well, very few people use multiple require directives, so I don't
> think it is so obvious.  And the default to the old Satisfy directive
> is All, which is equivalent to <SatisfyAll>.  Obviously there is no
> way to keep both of these old behaviors, so it winds up being a major
> change either way.
> Joshua.

View raw message