Code

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#4354 closed (invalid)

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

Reported by: nslater@… Owned by: adrian
Component: Core (Other) Version: master
Severity: Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

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 (0)

Change History (7)

comment:1 Changed 7 years ago by Simon G. <dev@…>

  • Component changed from Uncategorized to Core framework
  • Needs documentation unset
  • Needs tests unset
  • Owner changed from jacob to adrian
  • Patch needs improvement unset
  • 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)
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 7 years ago by SmileyChris

  • Resolution set to invalid
  • Status changed from new to closed

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.

comment:3 follow-up: Changed 7 years ago by anonymous

  • Resolution invalid deleted
  • Status changed from closed to reopened

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

comment:4 Changed 7 years ago 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.

comment:5 Changed 7 years ago by 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.

comment:6 in reply to: ↑ 3 Changed 7 years ago by SmileyChris

  • Resolution set to invalid
  • Status changed from reopened to closed

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.

comment:7 Changed 7 years ago 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 Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.