在重构为RubyAmf后，Rails似乎没有抱怨authenticity_token

Question

我正在构建Flex 4 + Rails 2.3.5应用程序。首先，我使用XML来传递日期，并且我曾经因为真实性令牌而抱怨我手动传递然后通过错误。

之后我重新考虑我的代码使用RubyAmf似乎正在工作，但我最初没有传入authenticity_token，但我注意到Rails没有抱怨并且请求已经完成。我的应用仍然没有取消注释protect_from_forgery。

RubyAmf会以某种方式绕过它吗？

谢谢，

担

Answer 1

我认为伪造保护不会因GET请求而触发，只有POSTS，DELETE和PUT。也许您正在测试的场景正在执行GET请求？

Answer 2

Ruby AMF直接调用控制器操作，并在序列化为AMF后返回结果。这与首先​​通过路由器的标准HTTP请求的工作方式相反。

Answer 3

更详细地解释camwest的答案：

当您向articles_controller，update操作发出AMF请求时，请求实际上并不直接转到该控制器和操作。此AMF请求（这是一个POST请求）实际上通过Rails路由器到达rubyamf_controller，gateway操作（AMF端点）。目标控制器和操作（articles_controller，update操作）被标记为此POST请求的参数。

此POST呼叫上设置的mime_type为amf。 RubyAMF插件将此mime_type添加到未检查伪造保护的mime_types列表中。因此，即使没有rubyamf_controller，对gateway，authenticity_token操作的调用也会成功完成。

从Flex，您可能已向articles_controller，update操作发送了一些参数。它们作为序列化的AMF对象到达gateway动作。这些参数在此处反序列化。

gateway操作会在内部调用目标控制器和操作（articles_controller，update操作）。目标操作执行其操作并返回响应。 gateway操作获取此目标操作的响应，将其序列化为AMF并将其发送回客户端。

在Rails 2.x中，此内部调用未调用伪造保护机制。因此，即使您不将authenticity_token作为参数之一发送到目标操作，也可以正常工作。

这在Rails 3中发生了变化。即使是内部调用也会调用伪造保护机制。目标操作检查是否存在authenticity_token参数。所以，你需要从Flex发送它。

更多信息：http://anjantek.com/2011/05/08/rails-3-rubyamf-flex-csrf-solution/