On Thu, Aug 1, 2013 at 6:55 PM, Mikhail T. <mi+t...@aldan.algebra.com> wrote: > 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): > > Check location /tiv/ -- granted, no problem. > Check location /tiv/index.php -- granted as well, so far so good. > 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...
That's not a bug at all. In some cases it may be necessary for authorization to run for sub-requests. If you're using the ap_register_auth_provider() system then you have some control over that by using AP_AUTH_INTERNAL_PER_CONF. > 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> I'm guessing you're using AP_AUTH_INTERNAL_PER_CONF which should avoid the 3rd call with the above configuration. > 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? Yes. In fact there are cases where subrequests are explicitly used to find out if a path is authorized. e.g. the -F and -U tests for RewriteCond: http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewritecond In fact it used to be worse in 2.2.x because AP_AUTH_INTERNAL_PER_URI was the old behavior. See this following text from http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html [[[ When possible, registering all access control hooks (including authentication and authorization hooks) using AP_AUTH_INTERNAL_PER_CONF is recommended. If all modules' access control hooks are registered with this flag, then whenever the server handles an internal sub-request that matches the same set of access control configuration directives as the initial request (which is the common case), it can avoid invoking the access control hooks another time. If your module requires the old behavior and must perform access control checks on every sub-request with a different URI from the initial request, even if that URI matches the same set of access control configuration directives, then use AP_AUTH_INTERNAL_PER_URI. ]]] > 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. Right that is how it would behave.
