在最新版本中，我们一直在Django中遇到重复CSRF令牌cookie的问题。我们刚刚从Django 1.4升级到1.6，而在1.4中再也没有任何问题。基本上，每个用户的一切都可以开始，但是在某些时候，他们最终会拥有多个CSRF令牌cookie，浏览器会感到困惑，并且不知道要使用哪个。它通常选择错误，并导致CSRF故障问题。我们的网站使用多个子域，因此通常有一个cookie用于.site.com，.sub.site.com，site.com和其他变体。
我们尝试将“ CSRF_COOKIE_DOMAIN”设置为.site.com，这似乎使该问题发生的频率降低了，但是当使用子域并且用户注销并以其他用户身份重新登录时，该问题仍然偶尔发生。
我们还发现，在我们的基本模板中未定义favicon快捷方式，从而导致了一个额外的请求通过中间件，但这是固定的。然后，我们确认只有真正的请求正在通过中间件，而没有任何静态或媒体文件。
我们仍然无法在命令中重现该问题，通常每当确实发生此问题时，清除cookie即可作为临时解决方案，但仍会定期发生。有谁知道为什么会这样？我们在文档中缺少什么？
谢谢。
编辑：
我忘记提及的一件事是，我们有多个服务器环境（site.com，demo.site.com和beta.site.com）。经过多一点的挖掘，看起来正在测试Beta然后使用过的产品的用户遇到了跨环境Cookie冲突。刚才我们尝试将每个环境的csrf cookie域设置为“ .beta.site.com”和“ .demo.site.com”，而不仅仅是“ .site.com”，这似乎很有用，尤其是当您清除自己的在每种环境下工作之间的cookie。但是，在生产中的.site.com Cookies之间仍然有可能在beta和demo中发生冲突，但这至少不是一个大问题。
那么，我们还有什么可以做的吗？此外，当用户将旧的“ site.com” cookie与新的指定“ .site.com” cookie发生冲突时，一旦将其推送到生产环境，我们还能做些什么？
编辑2：
我已经发布了解决方案，但是几天后我还是不能接受。
我想我们终于明白了。每个环境（“ .beta.site.com”，“。demo.site.com”等）的单独“ CSRF_COOKIE_DOMAIN”停止了跨环境问题。我们还最终将“ CSRF_COOKIE_NAME”设置为“ csrf_token”，而不是默认的“ csrftoken”，这样，使用旧的csrftoken cookie的用户就不会受到负面影响。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句