Django misuses the HTTP 401 Unauthorized header (either requires a WWW-Authenticate header or modification to return 403 Forbidden)

[nslater@…]

​http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

10.4.2 401 Unauthorized

The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). 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 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 might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43]. 

See contrib/auth/handlers/modpython.py:

def authenhandler(req, **kwargs):
    ...
    return apache.HTTP_UNAUTHORIZED

Django should not be using this response without also returning a correct WWW-Authenticate header field. The only response that makes sense in this context is a 403 Forbidden response as the authentication mentioned in the HTTP RFC is specifically HTTP authentication and not through the use of cookies.

[Chris Beaven]

I've been doing some work in this area. It seems that Apache adds the WWW-Authenticate header when the authenhandler function returns apache.HTTP_UNAUTHORIZED, so we don't need to do it.

[anonymous]

You forget that not everyone uses Apache. Django claims to be WSGI compliant.

[anonymous]

Additionally, if you reread the bug report you will see that that Django's use of the HTTP 401 Unauthorized header is incorrect. Even if Apache happens to correct the missing reply header for those people who use Apache it is still the wrong response to be returning for these requests.

[nslater@…]

Trac should really remember who I am or at least require login before I can comment. Needless to say, I was the author of the last two comments.

[Chris Beaven]

Replying to anonymous:

You forget that not everyone uses Apache. Django claims to be WSGI compliant.

This bug report is related the mod python auth handler which is specific to Apache, is it not?

Replying to anonymous:

Additionally, if you reread the bug report you will see that that Django's use of the HTTP 401 Unauthorized header is incorrect. Even if Apache happens to correct the missing reply header for those people who use Apache it is still the wrong response to be returning for these requests.

Django is not actually providing the request in this case, just the authentication handler, so I don't see what the problem is.

[Chris Beaven]

Correction: "Django is not actually providing the response...

So in summary, Apache still handles creating the response so

1) we can't add anything to the response and

2) if it just raises forbidden then the user will never be able to see it (since this handler relies on basic http auth)

In IRC, mattmcc said:

the Modpython docs say: "A return of apache.OK means the authentication succeeded. A return of apache.HTTP_UNAUTHORIZED with most browser will bring up the password dialog box again. A return of apache.HTTP_FORBIDDEN will usually show the error on the browser and not bring up the password dialog again. HTTP_FORBIDDEN should be used when authentication succeeded, but the user is not permitted to access a particular URL.

He's probably half right.

The handler returns unauthorized for both checks that it does, the auth check and the permissions check. The modpython docs suggest using forbidden if the permissions check fails.

My second patch in #3583 provides this alternate method.