httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: RequireAll: seems to evaluate require lines unnecessarily
Date Sun, 05 Aug 2012 20:39:11 GMT
On Sun, 5 Aug 2012, Graham Leggett wrote:
>> This works as designed. Authentication will only be triggered if the
>> end result depends on a valid user being present. The reason is to
>> avoid a password dialogue if the access will be denied anyway.
>
> This breaks basic authentication though, because basic auth relies on 
> that initial 401 Unauthorized to tell the client that a password is 
> required. In this case, access would have been approved, not denied, but 
> the client never got the opportunity to try log in as it was forbidden 
> from the outset.
>
> Right now, I cannot get aaa to work in either a browser or in the webdav 
> client for MacOSX with two require lines. In both cases, the user is 
> forbidden immediately with no opportunity to log in.

You mean you can't get "Require expr" to work. All other providers should 
work ok. Or do you have an example that does not involve "Require expr"?

>> I guess your approach would have been valid, too. But it causes other
>> problems since the user cannot influence the order in which require
>> directives are evaluated if AuthMerging is "or" or "and".
>
> In theory the evaluation should be done in the order that the directives appear in the
config file.
>
>> One could
>> have solved that with some additional directives like "AuthMerging or
>> prepend", etc., but that would get rather complex if one wants to keep
>> the full flexibility. I could imagine cases where additional require
>> lines would need to be evaluated in the middle of the inherited lines.
>
> How does inheritance work now?

The Require lines are evaluated in normal config merge order. This 
means that Require lines from <Directory> blocks are always evaluated 
before <Location>, etc.

>
>> For 2.4.x, we are now stuck with the current behavior. For 2.6/3.0, we
>> may of course consider to change it, if the alternative is better.
>
> Right now from what I can see the RequireAll directive isn't working at all, so to fix
it in v2.4 would just be a bugfix.

I disagree. It works except for "Require expr". And fixing it your way 
would cause behavior changes in many cases, not just for "Require expr".

>> 2.4.3 will give "require expr" some special casing for REMOTE_USER
>> that makes your use case work (see r1364266). PR 52892 has a
>> workaround that works with 2.4.2, too.
>>
>> If the special case for REMOTE_USER is not enough, one could add a
>> trigger_authn function that allows the same behavior for arbitrary
>> variables. E.g.
>>
>> Require expr %{note:mod_userdir_user} ==
>> trigger_authn(%{AUTHZ_VAR_FOO})
>
> I'm not convinced. Both AND and OR have behaviour dictated by the 
> principle of least astonishment, and I think it would be better for end 
> users for the behaviour to match what they expect, rather than try to 
> second guess what the end user wants with special cases.

If the interpretation of Require lines depends on the order, but you 
cannot influence the order in case of inheritance, then inheritance gets 
mostly useless. This is not the kind of change to make in a stable 
release.

Mime
View raw message