Ruby On Rails 框架包含一些功能，可以轻松构建公开 Web 服务 API 的服务器应用程序。例如，控制器执行以下操作：
respond_to :html, :json, :xml
def show
@thing = Thing.find(params[:id])
respond_with @thing
end
...将为两个 Web 浏览器处理“显示”操作，返回 HTML，并且还将项目“@thing”呈现为 JSON 或 XML，用于指定此数据格式的请求。
在此特定示例中，基于 GET 的“显示”操作不涉及任何特殊的安全措施。现在考虑与上述类似的情况，但对于诸如“创建”或“更新”之类的操作 - 由（模拟）PUT 或（实际）POST 请求激活的事物。现在 CSRF 保护开始发挥作用。
在这里，遗憾的是 Rails 似乎只是被设计来处理在同域网页中执行的 JavaScript 代码的“API 调用”（用于非 HTML 格式响应），对于任何可以向 Web 浏览器客户端提供 HTML 内容的控制器，其中 CSRF 保护是强制性的。 JavaScript 代码可以查找 Rails 包含的神奇“元”标签，读取 CSRF 令牌并将其提交回 XHR 调用，这些调用调用服务器上基于 POST 的操作或类似操作。
但是外部调用者呢？如果我们有 Rails 支持网站，但我们想要制作一个与同一个头端通信的本机 iOS 或 Android 应用程序，该怎么办？该应用程序将进行服务调用 - 很好，Rails 使这变得很容易 - 但任何修改服务器上数据的尝试都会失败，因为我们没有 CSRF 令牌。 我们不能绕过 CSRF 保护，因为相同的控制器代码可以处理 Web 浏览器以及“纯 API”客户端。
与 Rails 和 API 调用的 CSRF 问题相关的所有答案似乎都假设您针对这种情况有不同的控制器。但这是愚蠢的 - 如果仅对网页中的 JavaScript 代码有用，那么所有“让您的应用程序轻松公开为服务”的内容有什么意义，除非您在绕过 CSRF 的特殊控制器中复制一堆代码允许非网络客户端？这些额外的控制器只会增加攻击面。
有谁知道推荐的“正确”模式来处理 Rails 应用程序中的 CSRF 保护，这些应用程序的操作可能被 Web 浏览器或非 Web 浏览器客户端（例如本机 iOS 或 Android 应用程序）“调用”？像“respond_with(...)”这样的内置东西不会做任何有用的事情，比如总是生成一个 JSON/XML 对象，其中包含 CSRF 令牌作为无所不在的字段。我能想到的最好的办法就是自己做，例如将“@thing”渲染为：
{
csrf: "abcdef...7890",
object: { ...JSON representation of @thing... }
}
...但这看起来有点像黑客，需要做很多工作，而且似乎通过在每个请求上宣布最新的令牌来绕过 world+dog 的 CSRF。 一定有更好的方法:-)
嗯，docs say
开启请求伪造保护。请记住，仅检查非 GET、HTML/JavaScript 请求。
建议 JSON 和 XML 响应的请求已经不会被 csrf 检查，我认为这就是你的目标是什么？但实际上不是这样工作的吗？
您还可以覆盖控制器中的verify_authenticity_token，以拥有何时实际强制验证的自定义逻辑；这是一个非常简单的方法，调用其他实际的工作方法来进行验证并在未验证的情况下进行响应，因此您可以重写以仅在某些情况下进行验证检查（如果您需要的话）。或者不用覆盖，只需基于相同的想法编写自己的 before_filter ，并调用自己的 before 过滤器 - 查看源代码，这几乎就是
protect_from_forgeryverify_authenticity_token啊，我看到您链接到的注释宣布对“所有非GET请求”进行CSRF保护，所以我猜说它仅适用于HTML请求的文档已经过时了——但这让我觉得，这种变化的原因是什么？ （该公告并未准确记录该漏洞的性质，而且我也没有去寻找差异）。您当然可以以某种方式成功地取消此操作，并使 XML/JSON 请求不再检查 CSRF ——但是您是否会重新引入 3.0.4 想要修补的任何漏洞，这对您的应用程序来说重要吗？我不知道。