入力・確認・登録形式の画面遷移

徳丸 浩 @ockeghem

入力-確認-登録の画面で、確認時に入力エラーがあり無条件に入力に戻す場合はどうするのが定石なんでしょうね。(1)入力画面にリダイレクトする、(2)確認画面のURLで入力画面を出してしまう、(3)URLは全部同じで画面を出し分ける…一長一短があることだとは思いますが

eiryu @eiryu

@ockeghem (1)と(3)がいいんじゃないでしょうか？(2)は使ってる側も違和感を感じると思うので

やまざきkei5 @ymzkei5

@ockeghem (1)かしら。何かあったときにWebサーバのログから流れを読みやすいｗ ／WAFでホワイトリストや、画面遷移の限定（エントリページの指定）をするときに便利。（ぇｗ

やまざきkei5 @ymzkei5

@ockeghem (3)だと、“URL数”でお見積もりしているところは困るでしょうね。(笑

やまざきkei5 @ymzkei5

@ockeghem あははｗ　／“(1)と(2)の中間というか変形”のパターンだと、脆弱性があっても見つけられなくなる診断ツールがありそうですね。

のりぃ @m_norii

@ockeghem 自分が設計するときは(3)が多いですね。確認画面とかウィザード形式の時もそうですが、途中をブックマークされることを考えるとURLは同じで画面だけ出し分けの方がやりやすい、と思ってます。

Toru KAWAMURA @tkawa

@ockeghem Railsでは、デフォルトで確認画面というのはないのですが、入力値にバリデーションエラーがあったらURLはそのまま(2)が普通です。理由はわかりませんが、HTTP的に考えるとエラーなのに3xxを返すのは変ということかもしれません（でもたぶん200返してる）

Kenichi.Kus @kenichi_kus

@ockeghem 個人的にはいつも3です。セッション変数で分けています。アンケートとか取ってみて欲しいですね（笑）

Hideki SAKAMOTO @hs_onsky

@ockeghem DrupalやRuby on Railsでは標準的なエラーチェック処理を書くと入力画面のサブミット時に確認し、入力エラーがあればエラー表示付きの入力画面に戻り無ければ次に進むという感じで、確認画面以降でのチェックは実装し難いため、その作法に従っています

Hideki SAKAMOTO @hs_onsky

@ockeghem その際、エラーチェックを通った入力データをサーバに保持していわゆるワンタイムトークンを発行、確認画面以降ではそのワンタイムトークンをやり取りするような実装にして、後からの変更やCSRFへの対策としています.

まきのっぴ @pmakino

@ockeghem ユーザビリティ的な観点からの大前提として、確認時にエラーがあったら「空の入力画面」ではなく「各フィールドにユーザが入れた情報をセット済みの入力画面」を再表示すべきと思いますが、(1)だと (HTTPレベルのリダイレクトだと) それが実現困難なように思います。

まきのっぴ @pmakino

@ockeghem セッション変数を使ったり、HTTPでのリダイレクトではなくJavaScriptで強制POSTさせれば可能かもしれませんが、その程度のことにセッション変数を使うのはばかばかしいし、JavaScript依存になってしまうのもアクセシビリティ的に少々よろしくない。

まきのっぴ @pmakino

@ockeghem したがって(1)はなく、(2)か(3)のどちらかかなと私は考えています。

rryu🐋 @rryu2010

@ockeghem セッションを使う前提なら(1)で、POST遷移なら(3)で決まりですね。私はステートレスなPOST遷移の方が好きなのですが、戻るボタンが使いづらくなるのと、最近のフレームワークはURLベースでディスパッチするので作りづらいというのが辛いところです。