Code

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#12095 closed (fixed)

Login doesn`t work after django update to revision 11664

Reported by: venia Owned by: nobody
Component: Uncategorized Version: master
Severity: Keywords: csrf, auth, user
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

When i have updated django to revision 11664 i cann`t login. If i delete decorator "csrf_protect" in django.contrib.auth.views.login it became ok

Attachments (1)

12095.diff (1.2 KB) - added by lukeplant 4 years ago.
Patch for inclusion tag.

Download all attachments as: .zip

Change History (16)

comment:1 follow-up: Changed 4 years ago by lukeplant

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to worksforme
  • Status changed from new to closed

These views work fine for me. I presume the problem is a customised login template which doesn't include the {% csrf_token %} template. If that's not the problem, I'll need more information to diagnose.

I have now added an explicit note about this in the docs.

comment:2 in reply to: ↑ 1 Changed 4 years ago by anonymous

  • Keywords csrf, auth, user added
  • Resolution worksforme deleted
  • Status changed from closed to reopened

Replying to lukeplant:

These views work fine for me. I presume the problem is a customised login template which doesn't include the {% csrf_token %} template. If that's not the problem, I'll need more information to diagnose.

I have now added an explicit note about this in the docs.

{% csrf_token %} is included in my template, but it still doesn't work!

comment:3 Changed 4 years ago by lukeplant

  • Version changed from 1.1 to SVN

And I still need more information! What do you mean "it doesn't work"? What happens? If you turn DEBUG on, do you get any more information that might help diagnose this?

comment:4 Changed 4 years ago by anonymous

I'm using the built-in view django.contrib.auth.views.login and added {% csrf_token %} to my custom template (inside the form tag). This built-in view is using the csrf_protect decorator.

When I submit the login form I receive the following error:

403 Forbidden

CSRF verification failed. Request aborted.

Help

Reason given for failure:

    CSRF token missing or incorrect.
    
In general, this can occur when there is a genuine Cross Site Request Forgery, or when Django's CSRF mechanism has not been used correctly. For POST forms, you need to ensure:

The view function uses RequestContext for the template, instead of Context.
In the template, there is a {% csrf_token %} template tag inside each POST form that targets an internal URL.
You're seeing the help section of this page because you have DEBUG = True in your Django settings file. Change that to False, and only the initial error message will be displayed.

You can customize this page using the CSRF_FAILURE_VIEW setting.

comment:5 follow-up: Changed 4 years ago by lukeplant

Are you sure that you refreshed the page after adding the token? Could you 'view source' and see if the token has been included? If not, we need to work out why. Could you meet me on IRC? #django-dev on irc.freenode.net

Cheers.

comment:6 in reply to: ↑ 5 Changed 4 years ago by anonymous

There's no token included in the source. I've refreshed the page multiple times after adding the token.

<form action="{% url django.contrib.auth.views.login %}" method="post">{% csrf_token %}
	<table>
		<tr>
			<td>{{ form.username.label_tag }}</td>
			<td>{{ form.username }}</td>
		</tr>
		<tr>
			<td>{{ form.password.label_tag }}</td>
			<td>{{ form.password }}</td>
		</tr>
		<tr>
			<td></td>
			<td>
				<div class="submit">
					<input type="hidden" name="next" value="{{ next }}" />
					<input type="submit" class="button" value="Login" />
				</div>
			</td>
		</tr>
	</table>
</form>

Changed 4 years ago by lukeplant

Patch for inclusion tag.

comment:7 follow-up: Changed 4 years ago by lukeplant

We narrowed this down to an inclusion tag. I've attached a completely untested patch that is hopefully along the right lines, and might actually work. Despite the ugliness, this is probably better than requiring big changes for anyone who has used an inclusion tag for rendering a form.

emess, could you test it?

comment:8 in reply to: ↑ 7 Changed 4 years ago by emess

Replying to lukeplant:

We narrowed this down to an inclusion tag. I've attached a completely untested patch that is hopefully along the right lines, and might actually work. Despite the ugliness, this is probably better than requiring big changes for anyone who has used an inclusion tag for rendering a form.

emess, could you test it?

I can confirm that this fix is working. At least, it does for me right now.

comment:9 Changed 4 years ago by lukeplant

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

(In [11672]) Fixed #12095 - login and other contrib views failing if template rendered using inclusion tag.

The {% csrf_token %} tag is unable to get its value if a template is
rendered using an inclusion_tag, since that creates a brand new Context,
rather than using the existing one. Since this is a common pattern, and we
need CSRF protection to be as simple and easy as possible, we special case
the csrf_token and copy it from the parent context to the new context.

A more elegant and general solution may appear in future, but this is good
enough for now.

comment:10 Changed 4 years ago by thornomad

I am at revision [11681] and while the {% csrf_token %} is working for my accounts/login.html template (after I added it), it's not working for my comments/form.html template ... I am using the {% render_comment_form for object %} which, as I see it, maybe the only difference between the working accounts/login.html use and the comments/form.html use (am using django-threadedcomments, not the default).

comment:11 follow-up: Changed 4 years ago by lukeplant

My initial testing shows that {% render_comment_form %} works fine with {% csrf_token %} (although I don't have any real harness to test with). I'm guessing your problem is with django-threadedcomments, which we don't have control over.

comment:12 in reply to: ↑ 11 Changed 4 years ago by thornomad

Replying to lukeplant:

My initial testing shows that {% render_comment_form %} works fine with {% csrf_token %} (although I don't have any real harness to test with). I'm guessing your problem is with django-threadedcomments, which we don't have control over.

All right - thanks for your response. I'll have to keep searching. I had asked because django-threadedcomments's RenderCommentFormNode.render() looks exactly like the one in contrib.comments (see: http://github.com/ericflo/django-threadedcomments/blob/master/threadedcomments/templatetags/threadedcomments_tags.py).

I thought maybe it wasn't using RequestContext but I see no differences. I will try and see if the basic Comments app works as expected. Thanks.

comment:13 Changed 4 years ago by thornomad

I figured it out: I didn't have 'django.middleware.csrf.CsrfViewMiddleware' in my MIDDLEWARE_CLASSES ... am surprised that my accounts/login.html form worked using the tag without it this whole time ... that threw me off. Anyway - crises averted. Thanks. (I would delete my earlier comment if I could!)

comment:14 Changed 4 years ago by lukeplant

You don't need CsrfViewMiddleware for any views to work, so I'm troubled by that as an explanation. But I don't know what you meant by "it's not working for my comments/form.html". I'm guessing now that you meant that {% csrf_token %} was not producing any output in that page. If you weren't either using CsrfViewMiddleware or the csrf_protect decorator, then your comments form.html doesn't need the {% csrf_token %} tag, and it won't produce output either.

comment:15 Changed 4 years ago by carljm

I've just filed #12130, which I believe describes the continuing problems thornomad was experiencing.

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.