我正在将 Rails 应用程序从 5.2 升级到 6.1。以前我使用的是 5.1 默认值，现在我使用的是 6.1 默认值。
在 Rails 5.2 中，伪造保护成为默认设置。所以，当我一路升级到 6.1 时，一些事情开始出现问题。
我添加skip_forgery_protection到我的 graphql 控制器并修复了我所有失败的测试。没有测试访问其他控制器（肯定没有在前端实现伪造系统）失败，我手动尝试的其他事情也没有。
我的一个理论是 forgery_protection 仅适用于 POST、PUT、PATCH 和 DELETE，但我发现网上对此的讨论或提及为零，这似乎不是我所观察到的（尽管我承认我没有彻底测试该理论）。
一切都继承自同一个 ApplicationController
会发生什么？
我不确定我是否正确理解了您的问题。
但是，如果您问为什么 forgery_protection 仅适用于 POST、PUT、PATCH 和 DELETE，那么文档会说，
Turn on request forgery protection. Bear in mind that GET and HEAD requests are not checked.
从维基百科，
特别是，已经建立了约定，即 GET 和 HEAD 方法不应该具有采取除检索之外的操作的意义。这些方法应该被认为是“安全的”。这允许用户代理以特殊的方式表示其他方法，例如 POST、PUT 和 DELETE，以便用户意识到正在请求可能不安全的操作。
由于这个假设，Web 框架中的许多现有 CSRF 预防机制不会涵盖 GET 请求，而是仅将保护应用于旨在改变状态的 HTTP 方法。