いきなりタイトルをひっくり返すようだけれど、こう考えるほうが分かりやすい気がしてきた。

  • HTTPリクエストには、通常の操作で起こりえる「あり得るリクエスト」と、そうでない「あり得ないリクエスト」がある
  • 入力パラメータ(PHPだと例えば $_GET["hoge"])には、仕様上「正しい入力値」と、そうでない「正しくない入力値」がある

Strong Parametersの役割 は、「あり得ないリクエスト」を「あり得るリクエスト」に変換したり、例外としたりすることだ。だからこそ、モデルではなくコントローラに置かれた。

This new approach is an extraction of the slice pattern and we're calling the plugin for it strong_parameters (already available as a gem as well). The basic idea is to move mass-assignment protection out of the model and into the controller where it belongs.

The whole point of the controller is to control the flow between user and application, including authentication, authorization, and as part of that access control.

Riding Rails: Strong parameters: Dealing with mass assignment in the controller instead of the model

CSRF対策用のトークンが含まれない場合も「あり得ないリクエスト」。前回の記事でいう「あり得ない入力」がリクエストに含まれる場合も、「あり得ないリクエスト」として処理したければすればよい。

そうした処理を経れば、アプリケーションが処理すべきは「あり得るリクエスト」のみとなる。もちろん、「正しい入力値」と「正しくない入力値」の判別は済んでいないので、各入力パラメータの「バリデーション」が必要になる。

ユーザ入力のバリデーションは以上に尽きると思う。


ちなみに、以前の記事で触れた「ミクロ派」の主張(例:HTML構築時にも変数の文字エンコーディングをチェックすべき)は、ユーザ入力とは関係のない話だ。その変数はユーザ入力由来のものとは限らない。単純に、ぼくがテンプレートエンジンを作るとしたら、バインドされる変数の文字エンコーディングをチェックするだろう、といった程度の話だ。ライブラリやフレームワークが頑張ることで、アプリケーション開発者の負担や不安はむしろ軽減されるのではないか。