Django

Code

Ticket #4354 (closed: invalid)

Opened 3 years ago

Last modified 3 years ago

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

Reported by: nslater@gmail.com Assigned to: adrian
Milestone: Component: Core framework
Version: SVN Keywords:
Cc: Triage Stage: Accepted
Has patch: 0 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

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.

Attachments

Change History

05/26/07 08:25:31 changed by Simon G. <dev@simon.net.nz>

  • needs_better_patch changed.
  • component changed from Uncategorized to Core framework.
  • needs_tests changed.
  • summary changed from Django missuses the HTTP 401 Unauthorized header to Django misuses the HTTP 401 Unauthorized header (either requires a WWW-Authenticate header or modification to return 403 Forbidden).
  • owner changed from jacob to adrian.
  • needs_docs changed.
  • stage changed from Unreviewed to Accepted.

05/29/07 18:03:02 changed by SmileyChris

  • status changed from new to closed.
  • resolution set to invalid.

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.

(follow-up: ↓ 6 ) 05/29/07 19:12:47 changed by anonymous

  • status changed from closed to reopened.
  • resolution deleted.

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

05/29/07 19:16:04 changed by 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.

05/29/07 19:16:48 changed by nslater@gmail.com

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.

(in reply to: ↑ 3 ) 05/29/07 20:32:39 changed by SmileyChris

  • status changed from reopened to closed.
  • resolution set to invalid.

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.

05/29/07 21:59:12 changed by SmileyChris

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.

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




Change Properties
Action