在重构到RubyAmf之后，Rails似乎并没有抱怨authenticity_token

Question

我正在构建一个Flex4+ Rails 2.3.5应用程序。首先，我使用XML传递日期，我经常收到一个错误，抱怨我手动传递的身份验证令牌，然后才能通过这个错误。

在那之后，我重构了我的代码以使用RubyAmf，它似乎可以工作，但我一开始并没有传入authenticity_token，但我注意到Rails没有任何错误，请求也通过了。我的应用程序仍然有未注释的protect_from_forgery。

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

谢谢,

Tam

Answer 1

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

Answer 2

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

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列表中。因此，即使没有authenticity_token，对rubyamf_controller，gateway操作的调用也会成功完成。

在Flex中，您可能已经向articles_controller，update操作发送了一些参数。这些对象作为序列化的AMF对象到达gateway操作。这些参数在这里被反序列化。

然后，gateway操作在内部调用目标控制器和操作(articles_controller、update操作)。目标操作完成它的工作并返回一个响应。gateway操作获取此目标操作的响应，将其序列化为AMF并将其发送回客户端。

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

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

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