Login doesn`t work after django update to revision 11664

[venia]

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

[Luke Plant]

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.

[anonymous]

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!

[Luke Plant]

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?

[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.

[Luke Plant]

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.

[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>

[Luke Plant]

Patch for inclusion tag.

[Luke Plant]

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?

[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.

[Luke Plant]

(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.

[Damon Timm]

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).

[Luke Plant]

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.

[Damon Timm]

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.

[Damon Timm]

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!)

[Luke Plant]

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.

[Carl Meyer]

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