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?
Thank开发者_开发知识库s,
Tam
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.
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?
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/
精彩评论