如何在Rails中处理具有过时CSRF真实性令牌的页面

时间:2012-05-04 18:44:04

标签: ruby-on-rails session csrf

在我们的Rails应用程序中,用户通常会一次打开多个浏览器选项卡数小时或数天。在其中一个选项卡中,用户注销然后重新登录(或会话过期并创建新会话)时会出现问题。

这会导致所有其他选项卡上的CSRF真实性令牌变为无效。如果他们尝试在没有刷新的情况下提交任何表单或在这些选项卡上发出任何ajax请求,他们将收到错误(实际上会被注销,因为这是传递错误的真实性令牌时的默认Rails行为)。

这种行为显然是不受欢迎的。我想知道人们如何优雅地处理用户有一个窗口打开你的网站,但真实性令牌已过期的情况。

我不想做的只是将它们重定向到登录页面,因为这样他们可能会丢失他们的工作,例如他们已经写了很长的博客文章或其他东西。

想到的解决方案是使用一些javascript来轮询服务器以检查真实性令牌是否已更改,或者轮询用户的cookie以检查会话是否已更改。我从来没有听说有人做过这些,所以我想看看社区的想法。

2 个答案:

答案 0 :(得分:3)

首先:登录/退出/输入不会导致出现新的csrf-token。它仍将保存在用户的cookie中。下次通过同一浏览器登录时,它将获得相同的令牌。

在最新版本的Rails中,如果令牌不正确,则不会抛出任何错误:所有Rails都会执行 - 只需在将会话传递给控制器​​之前重置会话。

所以,更新你的Rails,你会少一点痛苦。

答案 1 :(得分:3)

您确定要谈的是CSRF令牌而不是会话令牌吗?完全没有任何意义重定向到登录CSRF令牌不匹配。您只需告诉用户重复他尝试做的任何事情。 (在传统的Web应用程序中,这通常在提交表单时出现;您可以将CSRF不匹配视为验证错误,并再次显示表单,保留所有字段值,并要求用户重新提交。在更多AJAX中 - 重要的应用程序,你可以在响应中使用某种通用的CSRF标志,如果设置了,请让用户再做一次(按下按钮等),甚至自动化整个事情而不用打扰用户。