You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by Lothar Belle <lo...@gmail.com> on 2018/11/02 12:29:18 UTC
imitExcept inside a Location overrules another Location restriction
We want to Allow only specific Methods i.e. HEAD POST GET.
so we are using.
<Location />
<LimitExcept HEAD POST GET>
Require all denied
</LimitExcept>
</Location>
Location is required, because we use mod_proxy, so no directory access is
performed.
Strangely it overrules a previous defined.
<Location /server-info>
SetHandler server-info
Require local
</Location>
So as a result server-info is accessible from everywhere.
According to my understanding, and documentation this behavior is not
correct.
*https://httpd.apache.org/docs/2.4/en/mod/core.html#limitexcept
<https://httpd.apache.org/docs/2.4/en/mod/core.html#limitexcept>:*
*<LimitExcept> and </LimitExcept> are used to enclose a group of access
control directives which will then apply to any HTTP access method not
listed in the arguments *
Thanks a lot!
Regards,
Lothar
Re: imitExcept inside a Location overrules another Location restriction
Posted by Lothar Belle <lo...@gmail.com>.
Eric, thank you for your quick answer.
I used the wrong mailing list. - which one is the right?
You wrote we should avoid Limit/LimitExcept in 2.4.
I tested it with 2.2 it works as expected.
But 2.2 is not really an alternative. What is the recommendation for
Limiting HTTP Methods in 2.4?
Am Fr., 2. Nov. 2018 um 13:47 Uhr schrieb Eric Covener <co...@gmail.com>:
> This is not a mailing list for reporting bugs, it's the mailing list used
> by bugzilla.
> Avoid Limit/LimitExcept in 2.4. In the config below, if the Location /
> comes second,
> it means the authorization config replaces the one defined in server-info,
> not merged with it, and GET is no longer limited.
>
>
> On Fri, Nov 2, 2018 at 8:28 AM Lothar Belle <lo...@gmail.com>
> wrote:
>
>> We want to Allow only specific Methods i.e. HEAD POST GET.
>> so we are using.
>> <Location />
>> <LimitExcept HEAD POST GET>
>> Require all denied
>> </LimitExcept>
>> </Location>
>> Location is required, because we use mod_proxy, so no directory access is
>> performed.
>> Strangely it overrules a previous defined.
>> <Location /server-info>
>> SetHandler server-info
>> Require local
>> </Location>
>> So as a result server-info is accessible from everywhere.
>> According to my understanding, and documentation this behavior is not
>> correct.
>> *https://httpd.apache.org/docs/2.4/en/mod/core.html#limitexcept
>> <https://httpd.apache.org/docs/2.4/en/mod/core.html#limitexcept>:*
>> *<LimitExcept> and </LimitExcept> are used to enclose a group of access
>> control directives which will then apply to any HTTP access method not
>> listed in the arguments *
>>
>> Thanks a lot!
>> Regards,
>> Lothar
>>
>>
>>
>>
>
> --
> Eric Covener
> covener@gmail.com
>
Re: imitExcept inside a Location overrules another Location restriction
Posted by Eric Covener <co...@gmail.com>.
This is not a mailing list for reporting bugs, it's the mailing list used
by bugzilla.
Avoid Limit/LimitExcept in 2.4. In the config below, if the Location /
comes second,
it means the authorization config replaces the one defined in server-info,
not merged with it, and GET is no longer limited.
On Fri, Nov 2, 2018 at 8:28 AM Lothar Belle <lo...@gmail.com> wrote:
> We want to Allow only specific Methods i.e. HEAD POST GET.
> so we are using.
> <Location />
> <LimitExcept HEAD POST GET>
> Require all denied
> </LimitExcept>
> </Location>
> Location is required, because we use mod_proxy, so no directory access is
> performed.
> Strangely it overrules a previous defined.
> <Location /server-info>
> SetHandler server-info
> Require local
> </Location>
> So as a result server-info is accessible from everywhere.
> According to my understanding, and documentation this behavior is not
> correct.
> *https://httpd.apache.org/docs/2.4/en/mod/core.html#limitexcept
> <https://httpd.apache.org/docs/2.4/en/mod/core.html#limitexcept>:*
> *<LimitExcept> and </LimitExcept> are used to enclose a group of access
> control directives which will then apply to any HTTP access method not
> listed in the arguments *
>
> Thanks a lot!
> Regards,
> Lothar
>
>
>
>
--
Eric Covener
covener@gmail.com