httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: check_user_access returns wrong code (fwd)
Date Tue, 13 Aug 1996 18:02:59 GMT
On Tue, 13 Aug 1996, "evan (e.n.) champion" wrote:

> At the end of mod_auth.c:check_user_access, if the user authenticated
> properly but is not authorised to access the given area (say, the user
> was not listed in the 'required' line), AUTH_REQUIRED is returned.
> This is IMHO (and according to my interpretation of the RFC) incorrect.  
> When check_user_access is executed, the server already accepts the user 
> is who he says he is and thus returning AUTH_REQUIRED is inappropriate.
> Instead, as the problem is that the user is not permitted to view the
> data, FORBIDDEN should be returned.

No, Apache's behavior is correct. Witness form your own spec excerpts:

>    401 Unauthorized
>    The request requires user authentication. The response must include
>    a WWW-Authenticate header field (Section 10.16) containing a
>    challenge applicable to the requested resource. The client may
>    repeat the request with a suitable Authorization header field
>    (Section 10.2). If the request already included Authorization
>    credentials, then the 401 response indicates that authorization has
>    been refused for those credentials. If the 401 response contains


See? In this case, the user agent has sent credentials, they may be valid
credentials, but they are not accepted in the current realm. So we tell
them they're denied. It's like walking into a store, taking a carton of
milk off the shelf, and then trying to pay for it with lyra (assume you're
in the United States). They may be perfectly valid lyra, but as far as the
store is concerned, you might as well be paying them in oak leaves.

>    the same challenge as the prior response, and the user agent has
>    already attempted authentication at least once, then the user
>    should be presented the entity that was given in the response,
>    since that entity may include relevant diagnostic information. HTTP
>    access authentication is explained in Section 11.
>    403 Forbidden
>    The server understood the request, but is refusing to fulfill it.
>    Authorization will not help and the request should not be repeated.


Not applicable here. Authorization *will* help. The correct authorization.
The request *can* be repeated. With the correct credentials.

>    If the request method was not HEAD and the server wishes to make
>    public why the request has not been fulfilled, it should describe
>    the reason for the refusal in the entity body. This status code is
>    commonly used when the server does not wish to reveal exactly why
>    the request has been refused, or when no other response is
>    applicable.
> Changing the return code would not create any serious problems and in
> fact would solve much more than it breaks.  The only problem created by
> changing the return code is that once a user authenticates properly they 
> would not be able to re-authenticate to access the same section if they 
> failed authorization. As an administrator, I think this is a good thing 
> as it at  least slows down people who try to force access to sites by
> making them restart their web  browser to re-authenticate.

Sorry, I don't buy this. Example: I help maintain a site that has a
password database, with about fifty usernames and passwords. We then have
fifty realms, each of which uses a different one of those users. If I type
in the wrong name accidentally (but still a valid one), I sure as heck
don't want to restart my browser just to get in. I want the browser to
re-prompt me for authentication.

> What we have done is modified our server source to return the proper
> error message, and then placed in new ErrorDocument documents to tell
> the user in plain words that the server understands who they are but
> won't let them in to that area, and that if they should have access to
> that area then they must contact the area owner to have this problem
> corrected.  If ErrorDocument can be used within <Directory> clauses, we
> will extend it further by specifying under what circumstances you will
> be allowed to access this section and who you have to contact to gain
> access.

-- Alexei Kosut <>            The Apache HTTP Server

View raw message