8

パラメータラッピング状態に関するドキュメント:

パラメータ ハッシュをネストされたハッシュにラップします。これにより、クライアントはルート要素を指定しなくても POST リクエストを送信できます。

どのパラメーター ハッシュがラップされているかを省略できます。Action Controllerの概要ガイドには、次の概要が記載されています。

paramsRailsは、クエリ文字列の一部として送信されるか、投稿本文の一部として送信されるかに関係なく、リクエストと共に送信されるすべてのパラメーターをハッシュで収集します。[…]query_parametersハッシュには、クエリ文字列の一部として送信されたパラメーターが含まれていますが、request_parametersハッシュには、投稿本文の一部として送信されたパラメーターが含まれています。ハッシュには、このpath_parameters特定のコントローラーとアクションにつながるパスの一部としてルーティングによって認識されたパラメーターが含まれています。

RESTful なリソースとルートを使用すると、楽しいことが起こります。has_many Bs を持つモデル A があるとします。したがって、B は外部キーを持ちますa_id

POST /as/1/bsのペイロードがあります (B には他のフィールドがないため)。a_idがであると仮定すると、 がオブジェクトにラップされるattr_accessibleと想定されるかもしれません。代わりに、次のように表示されます。a_idb

Processing by BsController#create as HTML
  Parameters: {"b"=>{}, "a_id" => "1"}

そのような幸運はありません。ParamsWrapperusesrequest_parameters and notが判明したparamsため、POST ペイロードに含めないa_idということは、ラップされないことを意味します。paramsURI グロビングのために にまだ含まれていることがわかり、なぜすべてのものから除外されたのか疑問に思うため、これはかなり紛らわしいです。

request_parametersここではなく使用する正当な理由はありparamsますか?

「REST 哲学」の観点からは、ペイロードにオブジェクト全体が含まれていると仮定した方がより純粋であることは理解できますが、それは基本的a_idに URI 内の が完全に無視されることを意味し、残念に思えます。

tl;dr: ParamsWrapperパラメータ ソースとして使用するrequest_parametersため、URI でグローバル化された変数はスキップされます。これはRailsのバグですか? 純粋な REST 支持者はノーと言うかもしれませんが、プラグマティズムはイエスを示唆しています。

4

2 に答える 2

0

私が理解している限り、「b」のハッシュに a_id が含まれていない理由は、データベースにレコードが存在するかどうかを最初に確認するためにその id 値が必要だからです。このようにして、リクエスト内の他のパラメーターを単純に拒否できます。「b」ハッシュに含めない理由によると、事故を防ぐことができます。次のシナリオを考えてみましょう: 誰かがフォームを更新し、完全な 'b' ハッシュを引数としてモデル オブジェクトに渡すとします。model_object.save を呼び出すと、セキュリティ上の脅威となる古いレコードを更新する代わりに、データベースにレコードが保存される場合があります (オブジェクトが以前に初期化されている場合に発生する可能性があります)。完全な証明シナリオではありませんが、コーディング中に事故が発生し、そのような事故を防ぐのに役立ちます.

于 2014-12-26T18:03:34.130 に答える