30.07.2013 19:18, I wrote:
>
> authorization result of Require all granted: granted
> authorization result of <RequireAny>: granted
> authorization result of AuthMerging Any: granted
> authorization result of Require all granted: granted
> authorization result of <RequireAny>: granted
> authorization result of AuthMerging Any: granted
> authorization result of Require tiv ipaddress: denied (no
> authenticated user yet)
> authorization result of Require tiv expiration: denied (no
> authenticated user yet)
> authorization result of <RequireAll>: denied (no authenticated
> user yet)
> authorization result of <RequireAny>: denied (no authenticated
> user yet)
>
After instrumenting mod_authz_core.c to provide a little more
information about the actual request_rec being processed, I got the
following output, which explains, what's happening.
The problem -- and I do think, it is a bug -- is that the entire
authorization is invoked not just for the request, but for the "internal
subrequests" too. So, in my scenario, when I asked for /tiv/, the authz
core made the following checks (color-coded to match the above-quoted
log-entries):
1. Check location /tiv/ -- granted, no problem.
2. Check location /tiv/index.php -- granted as well, so far so good.
3. We use mod_actions to hand-off processing of php-files to php-fpm,
so Apache also checks location */php-fpm/*tiv/index.php...
Because there is no explicit sublocation defined for /php-fpm/, the
rules for the Location / are invoked. Which leads to our tiv being
queried -- denying the request...
Items 1 and 2 explain, why I saw the "Require all granted" rule
processed twice in the log. Item 3 explain, why the rules of the top
Location got invoked at all...
I got things to work by changing the sub-location configuration to read
simply:
<LocationMatch ^(/php-fpm)?/tiv/>
Require all granted
DirectoryIndex index.php
</LocationMatch>
There is no need for AuthMerging even, after all. But I struggle to
understand, why the same HTTP-hit results in multiple processing of the
same authorization rules (some of which may, actually, be heavy...). Is
this really normal and expected behavior?
01.08.2013 21:05, Ben Reser wrote:
> If the resulting response is AUTHZ_DENIED_NO_USER then processing continues.
Is that so that if any of the subsequent children of the same RequireAll
say AUTHZ_DENIED, the server will not even bother figuring out the user?
Ok, makes sense, thank you. Turns out, this is not related to the main
problem, after all.
-mi
