我们构建了一个SaaS平台，允许用户通过预先确定的字母数字代码创建消息并在任何广告媒体上共享。
我们所有的表单都使用CSRF令牌，但我注意到了一个问题。如果用户正在编辑他们的消息，然后休息一下，然后返回完成编辑并点击保存，他们将面临CSRF不匹配的问题。警告信息。这是一个严重的问题，因为他们必须刷新页面，丢失更改，以便重新生成有效的令牌。
发生的事情是初始CSRF令牌是基于静态参数（例如filename和php_uname（））生成的，但它也是通过session_id（）生成的。因此，如果session_id发生更改，则会生成新的CSRF令牌，并且显然与旧令牌不匹配，从而产生警告消息。
在需要用户身份验证的表单上禁用CSRF保护会很容易，但我们有一些不需要身份验证的表单，例如用户登录。当然，要证明CSRF不匹配并不是什么大不了的事。在用户登录时，但对于不知道这意味着什么的用户来说，它看起来确实很糟糕，并最终将其搞砸了。并离开该网站。
因此，我正在寻找一种替代解决方案，以保持表面保护的一些外观，而不会产生毫无价值的警告信息。
两种可能的解决方案......
1）不是基于session_id生成基于CSRF的，而是根据一些cookie值生成它，这将允许优雅的跨会话处理。
2）完全放弃CSRF。相反，验证所有表单帖子的REFERER，如果它们与父域匹配，则继续。这将确保其他网站不会发布到我们的表单（CSRF的主要目的）。我们实际上将此解决方案用于我们的ajax请求。
我们倾向于选项＃2，但想检查是否还有其他优雅的解决方案需要考虑。
答案 0 :(得分：0)
我最终使用选项＃1（Cookie解决方案），并将CSRF种子视为持久登录cookie。如果种子在当前会话中不可用，请检查cookie（如果存在），填充当前会话。似乎运作良好，超越陈旧的会议。