You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ruediger Pluem <rp...@apache.org> on 2006/07/24 17:02:18 UTC
401 response with reject ip?
Having added the following to my virtual host
<location />
reject ip 127.0.0.1
</location>
results in a 401 response and the following entries in the error_log
[Mon Jul 24 16:56:03 2006] [error] [client 127.0.0.1] user (null): authorization
failure for "/":
[Mon Jul 24 16:56:03 2006] [error] [client 127.0.0.1] need AuthType to note auth
failure: /
Either I did the configuration wrong or the result is wrong. I think I should
get a 403 response instead and the message in the log should be something like
[Mon Jul 24 16:47:49 2006] [error] [client 127.0.0.1] client denied by server
configuration: /usr/src/apache/apache_2.0.x/htd
ocs/zw/formtest.html
Regards
Rüdiger
Re: 401 response with reject ip?
Posted by Brad Nicholes <bn...@novell.com>.
>>> On Mon, Jul 24, 2006 at 9:02 AM, in message <44...@apache.org>,
Ruediger Pluem <rp...@apache.org> wrote:
> Having added the following to my virtual host
>
> <location />
> reject ip 127.0.0.1
> </location>
>
> results in a 401 response and the following entries in the error_log
>
> [Mon Jul 24 16:56:03 2006] [error] [client 127.0.0.1] user (null):
> authorization
> failure for "/":
> [Mon Jul 24 16:56:03 2006] [error] [client 127.0.0.1] need AuthType to note
> auth
> failure: /
>
>
> Either I did the configuration wrong or the result is wrong. I think I
> should
> get a 403 response instead and the message in the log should be something
> like
>
> [Mon Jul 24 16:47:49 2006] [error] [client 127.0.0.1] client denied by
> server
> configuration: /usr/src/apache/apache_2.0.x/htd
> ocs/zw/formtest.html
>
>
>
> Regards
>
> Rüdiger
Well, I think that the following patch in mod_authz_core.c fixes the problem that you are looking at:
@@ -628,16 +633,25 @@
switch (auth_result) {
case AUTHZ_DENIED:
+ case AUTHZ_NEUTRAL:
/* XXX If the deprecated Satisfy directive is set to anything
but ANY a failure in access control or authz will cause
an HTTP_UNAUTHORIZED. Just the if statement
should be removed in 3.0 when the Satisfy directive
goes away. */
if (!note || (ap_satisfies(r) != SATISFY_ANY) || (note[0] == 'N')) {
- ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
- "user %s: authorization failure for \"%s\": ",
- r->user, r->uri);
- return_code = HTTP_UNAUTHORIZED;
+ if (r->ap_auth_type == NULL) {
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ "client denied by server configuration: %s",
+ r->filename);
+ return_code = HTTP_FORBIDDEN;
+ }
+ else {
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ "user %s: authorization failure for \"%s\": ",
+ r->user, r->uri);
+ return_code = HTTP_UNAUTHORIZED;
+ }
}
else {
return_code = DECLINED;
However, this brings up the question, what does "reject" actually mean? "Require" means that if true then authorization is granted otherwise authorization is denied. "Reject" obviously means that if true, then authorization is denied but it does not necessarily mean the opposite. So in the case that you defined:
> <location />
> reject ip 127.0.0.1
> </location>
obviously if the request is coming from 127.0.0.1 then the request is denied. But if the request comes from some other ip address, is authorization automatically granted? I don't think it is. There still needs to be a "Require" statement in the configuration somewhere.
Brad
Re: 401 response with reject ip?
Posted by Max Bowsher <ma...@ukf.net>.
Ruediger Pluem wrote:
> Having added the following to my virtual host
>
> <location />
> reject ip 127.0.0.1
> </location>
>
> results in a 401 response and the following entries in the error_log
>
> [Mon Jul 24 16:56:03 2006] [error] [client 127.0.0.1] user (null): authorization
> failure for "/":
> [Mon Jul 24 16:56:03 2006] [error] [client 127.0.0.1] need AuthType to note auth
> failure: /
Since the big authz refactoring, the authz system on trunk is buggy in
many different ways. I spent some time trying to analyse the problems a
while ago but got distracted by other projects before I had reached a
sufficient level of understanding to attempt fixing stuff.
Looking back at the notes I took, this is one of those problems.
I'll try to work out a useful set of bug reports.
(I take it no one is considering a 2.3.x branch any time soon? The authz
system is utterly unready for that.)
Max.