大垣さんと徳丸さんのパリデーション論争の感想

いずれの論点においても、ぼくは徳丸さんのご主張に共感するものだけれど、論争に参戦し、大垣さんを説得しようとは思わない。だって無理だもの。

人生は短いので、無理なことは極力避けたい。ぼくが徳丸さんだったら、PHP入門書の執筆を優先させることだろう。

追記(2013-07-24)

はっきりいえば、徳丸さん(あるいは徳丸さんの主張に賛同するもの)の戦うべき相手は、大垣さんではなく、彼が拠り所としている団体や規格、つまり「世界の常識」そのものなんじゃないかと思うんですよね。それらを引っくりかえせば、大垣さんの主張は根拠がなくなる。

敵が大きすぎて手に負えない、ということなら、ひとまず戦いは諦めて、「世界の常識」を無思慮に信じてしまいかねないWebアプリ開発者(特に初心者)を地道に啓蒙していくしかないんじゃないか。

それには、多少センセーショナルなキャンペーンが必要かもしれない。「駄目なセキュリティ文書の見分け方・その1=ホワイトリスト方式を推奨しているが肝心のホワイトリストが何なのか定義していない」など、Webアプリ開発の初心者でも理解できて、すぐに実践できるような。

続・「正しい入力」「あり得る入力」「あり得ない入力」の話

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

  • 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構築時にも変数の文字エンコーディングをチェックすべき)は、ユーザ入力とは関係のない話だ。その変数はユーザ入力由来のものとは限らない。単純に、ぼくがテンプレートエンジンを作るとしたら、バインドされる変数の文字エンコーディングをチェックするだろう、といった程度の話だ。ライブラリやフレームワークが頑張ることで、アプリケーション開発者の負担や不安はむしろ軽減されるのではないか。

記事検索
Twitter