5

我有一个网站和 CSRF 有点疯狂/令人愤怒的错误。

我们在 Ubuntu 上使用 Apache2 + mod_wsgi 运行 Django 1.2.3、Python 2.6，并让最终用户报告 403 CRSF 验证失败和 403s 结果。

我们所有的表格都有一个csrf_token和 - 据我所知 - 在本地开发人员和舞台上（我们还没有投入生产）......除了一个办公室（客户的，natch）。在随机情况下，他们会得到这样的 403，但随后刷新它就会消失（所以它不是缺少令牌的 HTML 等）

我正在考虑原因和解决方案，可能是那个办公室有一个非常急切或设置不当的代理缓存，或类似的，并且希望以 Django/Apache 的方式提供一些关于我们可以做什么的提示处理顶级代理（客户办公室可能不会更改他们的设置）或其他可能导致这些 CSRF 失败的原因。

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

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

4

1 回答 1

2

只是一个更新，以防它帮助任何人。

我们放弃了 CRSF 保护进行测试（通过使用http://johnmc.co/llum/disable-csrf-protection-for-django-1-2/）。这清除了 403s，但是对于来自同一个客户端/本地网络的零长度 POST 数据，我们有间歇性的 500s，这解释了 CSRF 失败是因为令牌存在于会话中但不存在于有效负载中（而不是其他方式）。

因此，具体而言，这不是 CSRF 问题，而是 POST-payload-getting-zapped-somewhere 问题。（很可能是由于仅在一个位置配置错误的代理）

高温高压

史蒂夫

于 2010-11-09T11:28:34.107 回答