Rails部署导致＆＃34;无法验证CSRF令牌真实性的峰值＆＃34;

Question

这是一个Rails 5.1 Web应用程序，从部署到Datica（基于Docker）的Rails 4应用程序（从Rails 3应用程序迁移）迁移。

在每次部署之后，我们的日志会记录出现'＃34;无法验证CSRF令牌真实性＆＃34;警告和相应的401状态。前端是一个React应用程序，大多数客户端 - 服务器通信发生在XHR上，因此有些人多次收到401。刷新浏览器已经解决了我两次的401状态，所以我认为峰值的下降表明人们刷新或停止使用该应用程序，因为它不适合他们（参见日志图的屏幕截图显示尖峰）。

该应用使用Cookie进行会话存储。首次加载时，CSRF令牌位于页面正文中。我所观察到的将通过cookie被赋予新的CSRF令牌来解释，因此页面正文中的CSRF令牌与会话中的CSRF令牌不匹配，但我不明白会导致服务器的原因部署后发出新的CSRF令牌。

认为这可能是由于接收到Origin标头的新启动实例的延迟，或旧实例停止接收它，我在application.rb中设置了config.action_controller.forgery_protection_origin_check = false。然而，在昨晚和今天早上再次部署之后出现了峰值（无论如何它都不会有意义，因为刷新浏览器似乎可以解决问题）。

有关部署如何导致服务器向会话发布新CSRF令牌的任何想法？或任何其他想法或其他假设？

谢谢！

Answer 1

问题是MyApp::Application.config.secret_key_base从未设置过。当应用程序从Rails 3迁移到4时，建议等到用户群完全打开4，然后取消注释该行。但这从未发生过。

我认为如果没有设置secret_key_base，它会自动生成一个用于生成CSRF令牌的内存中密钥库，从而在每次部署时产生一个新的密钥库。