Django 1.6中的CSRF令牌cookie问题

Question

我们最近在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 cookie在beta和demo之间仍然有冲突的可能，但至少这个问题减少了。

那么我们还能做些什么呢？另外，当我们把这个推向生产环境时，用户如果有旧的“site.com” cookie，和新的“.site.com” cookie发生冲突，我们能做些什么？

编辑2：

我已经发布了解决方案，但几天内无法接受。

Answer 1

我想我们终于搞明白了。为每个环境设置不同的“CSRF_COOKIE_DOMAIN”（比如“.beta.site.com”、“.demo.site.com”等）解决了跨环境的问题。我们还把“CSRF_COOKIE_NAME”改成了“csrf_token”，而不是默认的“csrftoken”，这样那些使用旧的csrftoken cookie的用户就不会受到影响了。