5
我有一个网站，并CSRF稍微疯狂/真气错误。间歇403S（Django的1.2.3）
我们的Ubuntu上运行的Django 1.2.3，Python的2.6的Apache2 + mod_wsgi的，并已获得最终用户报告403次CRSF验证失败和403S作为一个结果。
我们所有的表单都有一个csrf_token，据我所知，事情在本地开发和舞台上都能正常工作（我们还没有投入生产）......除了一个办公室（客户端，natch ）。在随机场合，他们会得到这样的403，但然后刷新，它会消失（所以它不是HTML缺乏令牌等）
我在思索的原因和解决方案，它可能是那个办公室有一个非常急于或设置不当的代理缓存或类似的问题，并且希望能够以Django/Apache的方式处理顶级代理（我们可以做的事情）的一些提示（客户办公室可能赢得了不会改变他们的设置），还有什么可能会导致这些CSRF失败。
BTW：这是一个从无到有的1.2.3项目，而不是某种1.1升级，而我们只使用单一的标准/正确1.2.3 CSRFMiddleware和手动添加csrf_tokens - 而不是CSRFResponseMiddleware自动包括csrf_token
另外：这发生在两个独立的服务器（开发服务器和登台服务器）上，这些服务器位于不同的位置。公共因素（理论上）与Django/Apache/mod_wsgi设置相同，代码库相同，办公室获得403s（并且不能在我们自己的位置复制403s）。