我对网站和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).