我们的错误日志偶尔包含导致ActionController::InvalidAuthenticityToken
错误的合法表单提交。
我的假设是,存储在用户会话cookie中的CSRF令牌在加载表单之后但在提交之前已经发生了更改。这会导致POSTed令牌与cookie中的令牌不匹配,从而导致此错误。
如果Rails会话cookie仅在浏览会话结束时(即当web浏览器关闭时)到期,那么在不关闭浏览器的情况下,如何更改此cookie (及其包含的CSRF令牌)?
我们使用cookie来存储会话数据,这是Rails的默认行为。
发布于 2017-01-17 22:20:06
以下是我们所知道的:
InvalidAuthenticityToken
异常的合法表单提交以某种方式丢失了原始的CSRF令牌。我现在认为,合法用户可以提交无效的CSRF令牌的方式有两种。
请注意,这些方法特别适用于Rails 4.2。据我所知,Rails 5中的“每种形式的CSRF令牌”功能可能会减轻它们的影响。
1.另一个选项卡中的会话更改
根据@crazymykl的回答,用户可以打开表单,然后在另一个选项卡中注销。这将导致存储在用户浏览器中的会话cookie发生更改。当它们返回到原始选项卡并提交表单时,来自表单的令牌将与会话中的令牌不匹配,并且会弹出错误。
2.缓存
根据这个rails错误,在某些情况下,Safari的缓存行为很奇怪。告诉它使用与上次相同的窗口重新打开(通过Safari > Preferences > General
),打开表单和退出Safari将导致表单被重新显示。
提交缓存的表单会导致CSRF错误。当bug的开场白结束时,Safari似乎缓存了页面,但删除了会话cookie。因此出现了错配。
这个问题的解决方案是使用指令Cache-Control
设置一个no-store
头。( no-cache
和no-store
的差异解释了这里)。
欢迎更多的例子:)。
发布于 2017-01-10 18:46:10
用户可以注销并重新登录,但是有一个选项卡,其中有一个从旧会话打开的表单。那会送出旧的记号。
发布于 2017-01-17 12:29:53
您是否使用Ajax表单来提交请求?您的页面有多个表单吗?如果是,请检查您的代码是否与请求一起提交了正确的csrf令牌。我们有类似的问题,页面是用一个csrf令牌呈现的,我们使用这个令牌来提交一个表单,我们本来可以得到另一个csrf令牌,但是第二个是发送导致错误的旧csrf令牌。我不知道这有什么帮助,但想和大家分享我面临的类似问题。
https://stackoverflow.com/questions/41482561
复制相似问题