httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch>
Subject Re: RequireAll: seems to evaluate require lines unnecessarily
Date Fri, 03 Aug 2012 07:25:05 GMT
On Thursday 02 August 2012, Graham Leggett wrote:
> I have a config like this using httpd v2.4, in an effort to
> password protect each person's userdir:
>     <RequireAll>
>       Require valid-user
>       Require expr %{note:mod_userdir_user} == %{REMOTE_USER}
>     </RequireAll>
> Hit it with a browser, and instead of 401 Unauthorized I'm getting
> 403 Forbidden instead, which prevents the basic authentication
> from kicking in and the user is denied.
> The log however shows something odd - despite the RequireAll
> directive being used, which implies AND behaviour, which in turn
> implies that require lines should be parsed until the first one
> fails and then the parsing should stop, both require lines are
> being evaluated even though the first line failed, and the result
> of the second require line is being sent instead.

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.

> In theory, in the RequireAll situation, require directives should
> be parsed until one fails, and the result of that failure returned
> to the client. All further require lines should be ignored as is
> standard behaviour for AND implementations. In the example above,
> the "authorization result of Require valid-user : denied (no
> authenticated user yet)" part should prevent the "authorization
> result of Require expr %{note:mod_userdir_user} == %{REMOTE_USER}:
> denied" part from being attempted at all.
> Can someone check whether my thinking is correct?

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". 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.

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.

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} == 

View raw message