CSRF cookie error only happening with Chrome.

[jkapple]

I have a site that is running Django 1.6.10. Recently some of our admins had trouble logging in and were getting the CSRF 403 error page. They had to delete all their cookies for the site to be able to login again. This led me to wonder if it was more widespread, since the CSRF error page doesn't get logged. I enabled logging and I'm seeing about 10% of posts having issues.

My Settings.py looks like this:

TEMPLATE_CONTEXT_PROCESSORS = (
'django.contrib.auth.context_processors.auth',
'django.core.context_processors.debug',
'django.core.context_processors.csrf',
'django.core.context_processors.i18n',
'django.core.context_processors.media',
'django.core.context_processors.request',
'django.core.context_processors.static',
)

MIDDLEWARE_CLASSES = (
'debug_toolbar.middleware.DebugToolbarMiddleware',
'django.middleware.cache.UpdateCacheMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.middleware.doc.XViewMiddleware',
'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware',

'linaro_django_pagination.middleware.PaginationMiddleware',

'django.middleware.cache.FetchFromCacheMiddleware',
)

The views causing the issue are generic class based views with a comment post form. The form has {% csrf_token %} inside the form tags. The error that is getting triggered is REASON_NO_CSRF from the csrf middleware.

<WSGIRequest
path:/accounts/login/,
GET:<QueryDict: {u'next': [u'/profile/edit/']}>,
POST:<QueryDict: {u'username': [REDACTED], u'csrfmiddlewaretoken':     
[u'Ns42nlyOUgLRUatcjjr0cfpRYwVSDETk'], u'password': [u'REDACTED']}>,
COOKIES:{'HIRO_COOKIE':     
'data=&newSession=false&id=REDACTED&timestamp=1414023546237',
'OX_plg': 'swf|shk|pm',
'SS_ARE_Override.traceLevel': 'WARN',
'__gads':   
'ID=b5f389086388b528:T=1413419752:S=ALNI_MaqCqguvaHWhG76FGjhHzPTieaGeA',
'__qca': 'P0-2120806691-1413419758360',
'__sonar': '749077714819215977',
'_bsef2f5b6aaad756f2445ed7606b648325': '1',
'acudeoSession.': '%7B%22time%22%3A1421376382060%2C%22adIndex%22%3A1%7D',
'ebNewBandWidth_.www.REDACTED.com': 'REDACTED',
'mlUserID': '9X8L0kMS8ypL',
'targus.BirthYear': '',
'targus.ap_seg': '',
'targus.gender': '',
'targus.matched': '1',
'targus.segment': '000',
'targus.zip': '',
'vsl_userid': 'c4ee281a94b19b5cb09d83ee93e98f55'},

META:{'CONTENT_LENGTH': '92',
'CONTENT_TYPE': 'application/x-www-form-urlencoded',
u'CSRF_COOKIE': u'CV5Vh0mpa578LnKGK1Lfj6pRVB1cwc6E',
'DOCUMENT_ROOT': '/usr/local/apache2/htdocs',
'GATEWAY_INTERFACE': 'CGI/1.1',
'HTTP_ACCEPT':     

'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;
q=0.8',
'HTTP_ACCEPT_ENCODING': 'gzip, deflate',
'HTTP_ACCEPT_LANGUAGE': 'en,en-GB;q=0.8',
'HTTP_CACHE_CONTROL': 'max-age=0',
'HTTP_CONNECTION': 'close',

The odd thing, this just started happening and it only affects Chrome user agents. I can step through with Chrome developer tools and see the a csrftoken cookie is present, but randomly after submitting, the error REASON_NO_CSRF gets triggered in the middle ware.

Doing the same exact thing in Firefox or Internet Explorer works fine. My Chrome install has no extensions running and is the latest 32 bit version.

[Tim Graham]

Unless you can provide information otherwise, it seems like Chrome's cookies are getting corrupted or something. Not sure Django can do anything about this.

[jkapple]

Replying to timgraham:

Unless you can provide information otherwise, it seems like Chrome's cookies are getting corrupted or something. Not sure Django can do anything about this.

It's happening on a somewhat largish scale, as it's not limited to just my computer. Out of 100s of posts, 10-20 are getting this error. I can provide screenshots of developer tools stepping through a submit if that would be helpful. I'm open to any suggestions on how to track this down as it is becoming a bigger nuisance every day.

[Tim Graham]

I suggest to use our support channels to get help, rather than this ticket tracker. If this proves to be a bug in Django, we can reopen the ticket. Thanks.

TicketClosingReasons/UseSupportChannels

[Yeago]

I'd love to provide any information needed. I am experiencing the same bug. To be clear, this started happening on a very large scale once I upgraded from 1.4.3 to 1.6.X.

It also mirrors a situation that's happening here: ​http://stackoverflow.com/questions/10264437/django-forbidden-csrf-cookie-not-set

A temporary fix for this seems to be to nuke the Chrome cookie. In corresponding with a user, I verified that a CSRF token in fact is populated before receiving the error.

[Tim Graham]

The way to help is by giving us steps so we can reproduce the error and debug it.

[Yeago]

I'd love to be able to reproduce it, still just debugging over email with users (lots of them).

The docs do say "Regardless, you’re guaranteed to have the cookie if the token is present in the DOM, so you should use the cookie!" is this true? If so, the error message "not set" seems errant.

[Yeago]

I was able to verify that the csrftoken in the form and the csrf cookie are both present and match before failure.

I was also able to take over a user's session normally by taking their cookie value and replacing my own locally with it. While their session actions still failed, my session was able to use the site normally (submitting forms, etc).

[Preston Timmons]

Which version of Django and Python are you seeing this on?

[Yeago]

py 2.7.8 / dj 1.6.10

[Preston Timmons]

This may be a bug in Python 2.7.8. Django uses the standard library Cookie implementation, which introduced some problems in recent releases. For example, ​https://bugs.python.org/issue22931.

Can you tell if another cookie is causing Cookie.load() to drop the csrftoken value during parsing?

[Yeago]

That's a bingo. As soon as I modified a local cookie to include a ], i instantly lost my django session (which makes no sense). The next login attempt was a bust. Removing the bracket restores my session :P Great find.

As for why Chrome users seem to report things far more than users of other browsers I leave up to the theologians. It was an uncanny red herring to this issue.

[Tim Graham]

Duplicate of #24492 which describes the problem more concisely.