最近Webアプリの開発手法について勉強しています。主にDjangoを使った開発で勉強しているのですが、今日はWebアプリ全般に共通する設計上の疑問が出てきたので備忘録します。疑問というのは、ログインしていない状態でデータ変更用URIにアクセスした場合、ログイン画面にリダイレクトするのが普通だと思います。で、そのログインに成功した後、どこにリダイレクトするべきなのか、という疑問です。
以下の仕様を前提にします:
- URI
/login/で、ログイン画面を表示する - URI
/item/ITEM_ID/で、IDがITEM_IDであるitemの詳細情報を表示する - URI
/item/ITEM_ID/delete/で、IDがITEM_IDであるitemを削除する - ログインしていないユーザにはitemの詳細情報を閲覧させない
- ただし未ログイン状態で閲覧URIにアクセスした場合はログイン画面を開き、正しいログイン情報を入力すれば指定されたitemの該当情報が表示される
- ログインしていないユーザにはデータを削除させない
上記を実現するのはさほど難しくありません。まず(1)未ログイン状態で表示・削除用のURI（仮にXとする）にアクセスされた場合、/login/?next=X などと「クエリー文字列にリダイレクト元のURIを指定したログイン画面のURI」へとリダイレクトさせ、続いて(2)ログイン画面ではリダイレクト元URIの指定がクエリー文字列に存在した場合はログイン後にそのURIへと遷移するようにしておけば実現できます。しかし、データ削除用URIにアクセスした場合もこの動作で良いのでしょうか…？
気にしているのは、削除URIへのアクセス直前でログインセッションがタイムアウトした場合です。つまり
- ユーザがログイン
- item 526の削除ボタンを表示
- ユーザが離席して長い時間が経過
- ユーザが戻ってきて削除ボタンを押す
- ログイン画面に強制遷移する
- また離席する
- ユーザが戻ってきてログイン情報を入力する
- item 526が削除される
こういう流れになると、最後のログイン情報入力時にユーザの頭には「先ほどまで削除操作をしていた」記憶が残っていないかもしれないと思います。すると「なぜかitem 526が消えている」という話になりそうな気がしています。
おそらく考えすぎなのだろうと思います。たとえばitemの削除後は、削除実行後に遷移する画面で「item 526を削除しました」等とメッセージを出せれば問題にならないのかもしれません。ただ、一般的にWebアプリの作りとして、ログイン画面にリダイレクトした後のリダイレクトバック先がデータ更新を伴うかどうかに応じて何らかの処理切り分けを行うのかどうか、気になります。