※ 商品リンクから購入されると少額の報酬が発生することがあります。
J2EEではアプリケーションサーバにビルトインされた認証のアルゴリズムがあります。
例えばtomcatにはダイアログベース（レスポンスコード403をブラウザに返す）ものとフォームベース（ユーザ・パスワードの入力画面を返す）ものが用意されています。
ただし、あるURIに対して参照する権限を有しているかどうかという種類の認証アルゴリズムなので、そのままでは利用できない局面が存在します。
一つの認証文字列（ユーザ・パスワードの組み合わせ）で、複数の権限グループあるいは一つの権限グループに複数の立場で属している場合には、デフォルトのままでは対処不能です。
そこで、認証後に複数の権限グループや立場から任意のものを一つ選択してもらう画面を用意することにしました。
が、J2EEにビルトインの認証機能の場合は、フォームの画面が返された後に認証に通ると、直前のリクエストデータが再ポストされます。
httpの仕様的に、 一度レスポンスが返された後にはリクエストデータは消えてしまっている はずです。
どのようにすれば良いのかと、tomcatと SerurityFilter をのぞいてみました。
tomcatでの実装
org.apache.catalina.authenticator.FormAuthenticator で認証処理やリクエストの保存・復元を行っていました。
これをいじってしまうと、認証メカニズム自体も変更しないと変なことになってしまいそうです。
SecurityFilterでの実装
org.securityfilter.filter.SecurityFilter で認証処理やリクエストの保存・復元を行っていました。
ただ、ServletAPI2.3のFilterを使用して実装されているので、J2EEの認証を残したまま特殊な処理を実装するのに便利そうです。
結局、上記の２種類の実装ともリクエストURIとリクエストデータの保存にはHttpSessionを使用していました。ということは作業中にセッションが切れて、再ログインする前に再びセッションが切れた場合には作業データは失われるということか。
ま、思いつく通りの内容だったといえましょうか。。。