Opened 13 years ago
Closed 11 years ago
#17216 closed Bug (duplicate)
Django contrib login view does not pass request to auth form on POST
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | contrib.auth | Version: | dev |
Severity: | Normal | Keywords: | auth, login |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Django auth login view pass request to auth form constructor on only on GET and not on POST.
I need this on post as well because it will enables doing additional validation in custom supplied auth form.
So how about the attached patch?
Attachments (1)
Change History (6)
by , 13 years ago
Attachment: | views.py.patch added |
---|
comment:1 by , 13 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 13 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
Triage Stage: | Unreviewed → Accepted |
Version: | 1.3 → SVN |
actually going to reverse myself here - while the default backend may be db - the cookie is still required for the sessionid - and in fact cookies are required for django auth to work.
So the entire code path that checks for cookies is not being used right now because of the missing request.
There are some other changes in the attached patch that don't seem to make sense, and new tests are needed - but this is a valid issue beyond just the need for access to the request.
Basically if you disable cookies - you will currently never get the error that cookies are required to login.
comment:3 by , 13 years ago
The current patch does not seem to be against trunk - also see http://groups.google.com/group/django-developers/browse_thread/thread/37c44fbd84516163# for comments on the use of data=request.POST or None
comment:4 by , 12 years ago
Status: | reopened → new |
---|
Sending the request to the standard AuthenticationForm assumes that you have cookies enabled as it will trigger a cookie capability check. However the default session backend is the database backend, not the cookie backend. So changing the default behavior of the view to pass the request would break sites that don't require cookies, with browsers with cookies disabled.
Since you are already providing a customized auth form - the solution in this case is just to provide your own login view as well