前回のつづき
アプリケーションコードの「何番目のテキストボックス」という処理は明らかに拙い。通常はプライマリキーとなるものも同時にビュー状態に持たせ、そのプライマリキーを
セッション状態と突合せるだろう。この対処によって、データDをデータC'に更新してしまう事は回避できる。しかし、データAはデータA''に更新される。
これでよいのだろうか？
場合によってはこの挙動でも問題ないだろう。ユーザーは最終的にはデータAをデータA''にしたいと考えているのだから。
しかし、そのような判断は一体どうやるのだろうか？しかも、他のデータが、「データA -> データA '->
データA''」といった遷移を前提とした処理をしていないのだろうか？
このような事に頭を悩ませるとキリがないので、「クライアントは、サーバーが返した最新のビュー状態で POST
する」という事を大前提としてシステムを作りあげる。このような前提を持ちたいが為によく用いられる手法が「ブラウザの戻るを禁止する」事だ。
これで万事解決…なわけがない。
「ブラウザの戻るを禁止する」にはツールバーを消す、キャッシュを残させない等、手法は幾つかある。確かに効果的あり、過去のビュー状態で
POST する確率を減らす事が出来るので、努力する価値はあると言える。しかし、あくまで確率を減らしているだけに過ぎない。
Web アプリケーション構築で絶対にしてはいけない事は、「クライアント側処理への絶対の信頼」だ。
Javascript によるクライアント検証、Cookie
の存在、環境変数、ありとあらゆるクライアント処理を信頼してはいけない。「ビュー状態は必ず最新である」という事も信頼してはいけない事はこれまでの話で分かる。
しかし、ビュー状態で信頼してよい事柄もある。それは「改竄されていない」という事だ。
ビュー状態の機密性はないに等しい。暗号化する事も可能だが、どうせクライアントに丸々渡してしまう物にパフォーマンスを落としてまで暗号化する意味があるかどうかは疑問だ。そもそも機密性が必要なデータをビュー状態に保存してはいけない。
それに対して、ビュー状態の正当性はフレームワークによって保障されている。
厳密には、改竄される可能性はあるが、改竄されたとしてもフレームワークが弾いてしまう。よって、我々はビュー状態が正当である事を前提としてシステムを構築できる権利がある。
ビュー状態が正当である事を前提として、ビュー状態が最新である事を保障したい。どうすればよいのか？
つづく。