我对网站和CSRF有一点点疯狂/令人愤怒的错误。
我们在Ubuntu上使用Apache2 + mod_wsgi运行Django 1.2.3，Python 2.6，并且最终用户报告了403 CRSF验证失败和403s。
我们所有的表格都有一个csrf_token而且 - 据我所知 - 在当地开发和舞台上（我们尚未投入生产）的事情都很好......除了一个办公室（客户，自然）。在随机的场合，他们会得到这样的403，但随后刷新并且它会消失（因此不是缺少令牌的HTML等）
我正在考虑原因和解决方案，而且可能是办公室有一个极度过于热切或设置不佳的代理缓存或类似的东西，并且会欣赏一些关于我们可以做什么的提示，在Django /中Apache处理over-the-top代理的方式（客户办公室可能不会改变他们的设置）或者其他可能导致这些CSRF失败的原因。
BTW：这是一个1.2.3项目从头开始，而不是某种1.1升级，我们只使用单一标准/正确的1.2.3 CSRFMiddleware并手动添加csrf_tokens - 而不是CSRFResponseMiddleware自动包含csrf_token另外：这发生在两个独立的服务器（开发服务器和登台服务器）上，这些服务器托管在不同的位置。常见的因素是（理论上）相同的Django / Apache / mod_wsgi设置，相同的代码库和同一个办公室获得403s（并且无法在我们自己的位置复制403）。
答案 0 :(得分：2)
只是更新以防万一。
我们放弃了CRSF保护以进行测试（使用http://johnmc.co/llum/disable-csrf-protection-for-django-1-2/）。这清理了403s，但后来我们从同一个客户端/本地网络获得零长度POST数据的间歇性500s，这解释了CSRF失败是因为令牌存在于会话中但不存在于有效载荷中（而不是其他方式）。
因此，这不是一个CSRF问题，特别是一个POST-payload-getting-zapped-somewhere问题。 （最有可能是在一个位置配置错误的代理）
HTH
史蒂夫