我们在最近的版本中遇到了Django中重复的CSRF令牌cookie的问题。我们刚刚从Django 1.4升级到1.6，我们在1.4中从未遇到过任何问题。基本上，每个用户的一切都很好，但在某些时候，他们最终会有多个CSRF令牌cookie，浏览器会混淆并且不知道使用哪个。它通常选择错误并导致CSRF失败问题。我们的网站使用多个子域，因此通常会有.site.com，.sub.site.com，site.com和其他变体的cookie。
我们尝试将“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 cookie在测试版和版本中的生产碰撞之间仍有可能发生冲突，但这至少不是问题。
那么我们还能做些什么吗？此外，当用户将旧的“site.com”cookie与新指定的“.site.com”cookie发生冲突时，我们可以将其推向生产状态吗？
编辑2：
我发布了解决方案，但它不会让我接受它几天。
答案 0 :(得分：0)
我想我们终于明白了。单独的＆＃34; CSRF_COOKIE_DOMAIN＆＃34;对于每个环境（＆＃34; .beta.site.com＆＃34;，＆＃34; .demo.site.com＆＃34;等）停止了跨环境问题。我们最终还设置了＃CSR; CSRF_COOKIE_NAME＆＃34;到＆＃34; csrf_token＆＃34;而不是默认的＆＃34; csrftoken＆＃34;因此，使用旧csrftoken cookies的用户不会受到负面影响。