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} ==
trigger_authn(%{AUTHZ_VAR_FOO})
