Flex 4 +Rails2.3.5アプリケーションを構築しています。最初はXMLを使用して日付を渡していましたが、手動で渡したAuthenticity Tokenについて不平を言うエラーが発生し、その後エラーを通過していました。
その後、動作しているように見えるRubyAmfを使用するようにコードをリファクタリングしましたが、最初はauthenticity_tokenを渡さなかったのですが、Railsが文句を言わず、リクエストが通過したことに気付きました。私のアプリにはまだコメントなしのprotect_from_forgeryがあります。
RubyAmfはどういうわけかそれをバイパスしますか？
ありがとう、
タム
偽造保護は、GETリクエストに対しては発動せず、POSTS、DELETE、およびPUTに対してのみ発動すると思います。テストしているシナリオがGETリクエストを実行しているのではないでしょうか。
Ruby AMFはコントローラーアクションを直接呼び出し、AMFにシリアル化した後に結果を返します。これは、最初にルーターを通過する標準のHTTPリクエストがどのように機能するかとは対照的です。
camwestの答えをもう少し詳しく説明するには：
articles_controllerたとえば、アクションに対してAMFリクエストを行う場合update、リクエストは実際にはそのコントローラーとアクションに直接送信されません。このAMFリクエスト（POSTリクエスト）は、実際にはRailsルーターを介してアクション（AMFエンドポイント）に到達しrubyamf_controllerますgateway。宛先コントローラーとアクション（articles_controller、updateaction）は、このPOSTリクエストのパラメーターとしてタグ付けされます。
mime_typeこのPOST呼び出しのセットはですamf。RubyAMFプラグインは、これmime_typeを偽造保護がチェックされていないmime_typesのリストに追加します。したがって、アクションの呼び出しは、rubyamf_controllerがgatewayなくても正常に実行されauthenticity_tokenます。
Flexからarticles_controller、updateアクションにいくつかのパラメーターを送信した可能性があります。これらは、アクションへのシリアル化されたAMFオブジェクトとして到着しますgateway。これらのパラメータはここで逆シリアル化されます。
次に、gatewayアクションは内部でターゲットコントローラーとアクション（articles_controller、updateaction）を呼び出します。ターゲットアクションはその処理を実行し、応答を返します。アクションは、このgatewayターゲットアクションの応答を取得し、それをAMFにシリアル化して、クライアントに送り返します。
Rails 2.xでは、この内部呼び出しは偽造保護メカニズムを呼び出しませんでした。authenticity_tokenしたがって、パラメータの1つとしてをターゲットアクションに送信しなくても、正常に機能します。
これはRails3で変更されました。内部呼び出しでさえ偽造保護メカニズムを呼び出します。ターゲットアクションは、パラメーターの存在をチェックしauthenticity_tokenます。したがって、Flexから送信する必要があります。
詳細はこちら：http ：//anjantek.com/2011/05/08/rails-3-rubyamf-flex-csrf-solution/