CSRF故障导致间歇性403s（Django 1.2.3）

我有一个网站和CSRF有点疯狂/恼火的bug

我们使用Apache2+mod_wsgi在Ubuntu上运行Django 1.2.3和Python 2.6，最终用户报告了403次CRSF验证失败，结果是403次

我们所有的表单都有一个

csrf\u令牌

，而且——据我所知——在本地开发和舞台上一切正常（我们还没有投入生产）。。。除了一个办公室（客户的，natch）。在随机的情况下，他们会得到这样一个403，但是刷新之后，它就会消失（所以不是HTML缺少标记等）

我正在思考原因和解决方案，可能是该办公室的代理缓存过于急切或设置不当，或者类似的问题，如果我们能以Django/Apache的方式处理顶级代理（客户的办公室可能不会更改其设置），我将非常感谢您提供一些建议或者是什么原因导致这些CSRF失效

顺便说一句：这是一个从头开始的1.2.3项目，不是某种1.1升级，我们只使用单个标准/正确的1.2.3 CSRFMiddleware和手动添加的csrf_令牌，而不是CSRFResponseMiddleware来自动包含csrf_令牌

---

另外：这发生在两个独立的服务器上（dev服务器和staging服务器），它们托管在不同的位置。共同因素（理论上）是相同的Django/Apache/mod_wsgi设置、相同的代码库和相同的办公室获得403（并且无法在我们自己的位置复制403）。

只是一个更新，以防它对任何人都有帮助

我们放弃了CRSF保护以进行测试（通过使用）。这清除了403，但是我们对来自同一客户机/本地网络的零长度POST数据进行了间歇500s，这说明CSRF失败是因为令牌存在于会话中，而不存在于有效负载中（而不是相反）

所以，这不是一个CSRF问题，具体来说，而是一个后有效载荷被击中的问题。（最有可能是由于一个位置的代理配置错误）

嗯

史蒂夫