after refactoring to RubyAmf Rails doesn't seem to complain about authenticity_token

Question

I'm building a Flex 4 + Rails 2.3.5 application. First I was using XML to pass date through and I used to get an error complaining about Authenticity Token which I passed manually then to get through the error.

After that I re-factored my code to use RubyAmf which seems to be working but I didn't pass in the authenticity_token at first but I noticed that Rails didn't complain and the request went through. My app still have protect_from_forgery uncommented.

Does RubyAmf bypass that somehow?

Thanks,

Tam

score 1 · Answer 1 · answered Mar 06 '10 at 18:10

1

I believe forgery protection does not fire off for GET requests, only POSTS, DELETE and PUTs. Maybe the scenario you're testing is executing a GET request?

answered Mar 06 '10 at 18:10

Jose Fernandez

270
2
9

With rubyamf I can send a POST requests – Tam Mar 06 '10 at 20:43

score 1 · Accepted Answer · answered Mar 06 '10 at 18:15

1

Ruby AMF directly calls controller actions and returns the results after serializing to AMF. This is opposed to how a standard HTTP request works which goes through the router first.

answered Mar 06 '10 at 18:15

camwest

312
1
8

forgery protection is fired off by the controller as a before_filter, shouldn't matter if the router called it or not – Jose Fernandez Mar 06 '10 at 19:54

score 1 · Answer 3 · answered Oct 20 '11 at 12:34

To explain camwest's answer in a little more detail:

When you make an AMF request to, say, the articles_controller, update action, the request doesn't actually go to that controller and action directly. This AMF request (which is a POST request) actually reaches the rubyamf_controller, gateway action (AMF end point) through the Rails router. The destination controller and action (articles_controller, update action) are tagged on as parameters to this POST request.

The mime_type set on this POST call is amf. The RubyAMF plugin adds this mime_type to the list of mime_types that are not checked for forgery protection. Hence, the call to the rubyamf_controller, gateway action goes through successfully, even without the authenticity_token.

From Flex, you may have sent some parameters to the articles_controller, update action. These arrive as a serialized AMF object to the gateway action. These parameters are deserialized here.

The gateway action then internally calls the target controller and action (articles_controller, update action). The target action does its stuff and returns a response. The gateway action obtains the response of this target action, serializes it into AMF and sends it back to the client.

In Rails 2.x, this internal call did not invoke the forgery protection mechanism. So, even if you do not send the authenticity_token as one of the parameters to the target action, it works fine.

This changed in Rails 3. Even the internal call invokes the forgery protection mechanism. The target action checks for the presence of the authenticity_token parameter. So, you need to send it from Flex.

More here: http://anjantek.com/2011/05/08/rails-3-rubyamf-flex-csrf-solution/

after refactoring to RubyAmf Rails doesn't seem to complain about authenticity_token

3 Answers3