httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Reser <>
Subject Re: Resolved (sort of): Struggling with AuthMerging
Date Fri, 02 Aug 2013 02:47:12 GMT
On Thu, Aug 1, 2013 at 6:55 PM, Mikhail T. <> 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

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

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.

View raw message