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.
