On 12/4/2008 at 1:30 PM, in message [EMAIL PROTECTED], Chris
Darroch [EMAIL PROTECTED] wrote:
Hi --
Eric Covener wrote:
I had meant iif containers are used, I'd like their name to
communicate the require or reject part while the authz providers
would be match-like (because the Require on
Hi --
Eric Covener wrote:
I had meant iif containers are used, I'd like their name to
communicate the require or reject part while the authz providers
would be match-like (because the Require on the inside is confusing
when surrounted by all the variations)
Yes, I thought that was a good
IIRC, trunk contains (or contained) a security problem with regard to
backward compatibility with 2.x configs. I won't consider it releasable
until that has been fixed one way or another, and I can't tell from this
mail thread whether the actual fix was committed or not. I thought that
Chris
Roy T. Fielding wrote:
IIRC, trunk contains (or contained) a security problem with regard to
backward compatibility with 2.x configs. I won't consider it releasable
until that has been fixed one way or another, and I can't tell from this
mail thread whether the actual fix was committed or not.
On Mon, Dec 1, 2008 at 6:16 PM, Chris Darroch [EMAIL PROTECTED] wrote:
Finally there was a certain amount of bike-shed re-painting in
the form of renaming configuration directives. I settled on
Match, MatchAll, etc. based on Eric Covener's comments.
I had meant iif containers are used, I'd
On Dec 1, 2008, at 3:16 PM, Chris Darroch wrote:
Roy T. Fielding wrote:
IIRC, trunk contains (or contained) a security problem with regard to
backward compatibility with 2.x configs. I won't consider it
releasable
until that has been fixed one way or another, and I can't tell
from this
-Ursprüngliche Nachricht-
Von: Chris Darroch
Gesendet: Dienstag, 4. November 2008 02:14
An: dev@httpd.apache.org
Betreff: Re: AuthzMergeRules blocks everything in default
configuration
Ruediger Pluem wrote:
I was hoping that your patches would fix this, but sadly
Dan Poirier wrote:
I'd find it much easier to understand if we had fewer directives, and
just built up the more complicated ideas by writing boolean expressions,
which most of us already know how to cope with.
Perhaps, and the underlying code should support a range of alternative
On 11/03/2008 08:12 PM, Chris Darroch wrote:
Dan Poirier wrote:
I'd find it much easier to understand if we had fewer directives, and
just built up the more complicated ideas by writing boolean
expressions, which most of us already know how to cope with.
Perhaps, and the underlying
Ruediger Pluem wrote:
I was hoping that your patches would fix this, but sadly they did not.
Ironically, the problem appears to have little to do with authz,
but rather authn. The test httpd logs show it's failing to find
an htpasswd-type file in which to check the user's login and
Chris Darroch said the following on 10/29/2008 10:35 PM:
Directory /humans_and_friendlies_only
Require valid-user
SatisfyNotAll
Require group alien
SatisfyAny
Require group hostile
Require group neutral
Require group noninterventionist
/SatisfyAny
/SatisfyNotAll
Dan Poirier wrote:
I like the idea of replacing ON with AND and OR. It would not
only provide more control, but make it explicit what kind of merging
was going to happen.
I have mixed thoughts about changing the default to OFF.
Cons: That would mean every container directive would have to
On Wed, Oct 29, 2008 at 6:17 PM, Chris Darroch [EMAIL PROTECTED] wrote:
The MergeAuthzRules directive is renamed SatisfySections and
take three possible values, Off, All, and And. The default is Off,
meaning that as directory configuration sections are merged,
new authz configurations
Eric Covener wrote:
I tend to prefer something closer to the old name, especially with the
Satisfy containers being optional. IOTW the sections here may not
be something explicit the user can look back to.
(Maybe IOW, in other words? :-)
They should be: since Directory and friends all
On Tue, 23 Sep 2008 11:05:45 -0700, Chris Darroch
[EMAIL PROTECTED] said:
Dan Poirier wrote:
...
I read through some previous discussion of the authz inheritance
behavior, but it doesn't seem to have considered the effect of having
Require all denied at the top level, which is overriding
On Mon, Oct 6, 2008 at 9:34 AM, Dan Poirier [EMAIL PROTECTED] wrote:
One other idea occurs to me. Would it seem more intuitive if a
context that had no authz directives inherited the settings from its
predecessor, but as soon you added authz directives, it behaved as if
you were starting
On 10/06/2008 03:59 PM, Eric Covener wrote:
On Mon, Oct 6, 2008 at 9:34 AM, Dan Poirier [EMAIL PROTECTED] wrote:
One other idea occurs to me. Would it seem more intuitive if a
context that had no authz directives inherited the settings from its
predecessor, but as soon you added authz
I hate to re-open this can of worms, but...
Unless I'm missing something, in trunk right now, uncommenting includes
for the examples like extra/httpd-manual.conf does not result in being
able to serve the documentation pages.
In the main config file:
Directory /
Require all denied
18 matches
Mail list logo
