I’ve got a slightly crazy/infuriating bug with a site and CSRF.
We’re running Django 1.2.3, Python 2.6 on Ubuntu with Apache2 + mod_wsgi and have been getting end users reporting 403 CRSF verification failures and 403s as a result.
All our forms have a csrf_token and – as far as I am aware – things work fine in local dev and on stage (we’re not in production yet)… apart from for one office (the client’s, natch). On random occasions, they’ll get such a 403, but then refresh and it’ll go away (so it’s not the HTML lacking a token etc)
I’m pondering causes and solutions, and it may be that that office has a fiendishly over-eager or poorly set-up proxy cache, or similar, and would appreciate some tips on what we can do, in a Django/Apache way to deal with over-the-top proxies (the client’s office likely won’t change their setup) or what else might be up to cause these CSRF fails.
BTW: this was a 1.2.3 project from scratch, not some kind of 1.1 upgrade, and we use just the single standard/correct 1.2.3 CSRFMiddleware and manually added csrf_tokens – not the CSRFResponseMiddleware to automatically include the csrf_token
Also: this has happened on two separate servers (dev server and staging server), which are hosted in separate locations. Common factors are (in theory) same Django/Apache/mod_wsgi setup, the same codebase and the same office getting the 403s (and not being able to replicate the 403s in our own location).
just an update in case it helps anyone.
We dropped the CRSF protection to test (by using http://johnmc.co/llum/disable-csrf-protection-for-django-1-2/). This cleared up the 403s, but then we had intermittent 500s for zero-length POST data from the same client/local network, which explained that the CSRF fails were because the token was present in the session but not in the payload (rather than the other way around).
So, it wasn’t a CSRF issue, specifically, but a POST-payload-getting-zapped-somewhere issue. (Most likely by a misconfigured proxy at just one location)
HTH
Steve