间歇403S由于CSRF故障（Django的1.2.3）

Question

我有一个网站，并CSRF稍微疯狂/真气错误。

我们的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

此外：这发生在两个不同的服务器（dev的服务器和分期服务器），其在单独的位置托管。常见的因素是（理论上）相同的Django /阿帕奇/ mod_wsgi的设置，同样的代码库和同一个办公室得到403S（和不能够复制403S在我们自己的位置）。

Answer 1

，以防万一更新它有助于任何人。

我们扔下CRSF保护测试（通过使用 HTTP ：//johnmc.co/llum/disable-csrf-protection-for-django-1-2/ ）。该清理的403S，但后来我们不得不对零长度POST数据间歇500S来自同一客户端/本地网，这解释说，CSRF失败是因为令牌存在于该会话，但不是在有效载荷（而不是其他方式）。

所以，这不是一个CSRF问题，尤其是，但后有效载荷越来越-轮回一圈，什么地方的问题。 （由仅在一个位置错误配置的代理可能大多数）

HTH

史蒂夫