はじめに
DreamHanksの松下です。
前回はDBの勤務時間管理TBLを登録/更新処理を解説しました。
セッションを使ってサーバーに一定期間ログイン情報を保持させるやり方を解説いたします。
セッションとは(前知識)
- WebブラウザとWebサーバがHTTP通信で接続される
- Webブラウザが要求を出す
- Webサーバが応答を返す
- 接続を切断する
この一連の流れを「セッション」と言います。
ECサイトで「商品Aを購入」というボタンをクリックしたとします。
これをセッションAとしましょう。
続けて、「商品Bを購入」というボタンをクリックしたとします。これをセッションBとしましょう。
このユーザは商品Aと商品Bを購入したいわけですね。
しかし、Webサーバにとっては、セッションAとセッションBは無関係です。
つまり、「商品Aを購入」ボタンを押したユーザと「商品Bを購入」ボタンを押したユーザとは無関係ということになります。これでは困りますね。
そこで、これらのセッションをひとまとめにする仕組みが必要になります。
これが「セッション管理」です。
セッションID
セッション管理をするためにリクエストのあったユーザ(Webブラウザ)を識別することが必要になります。
Webサーバは、セッション管理が必要になった時点で、Webブラウザに「セッションID」という番号を渡します。
Webブラウザは、その後で同じWebサーバにアクセスするときに、このセッションIDをWebサーバに渡します。
このセッションIDによって、ユーザ(Webブラウザ)を識別します。
セッションIDの渡し方にはいくつか方法があります。
ここでは、「Cookie」と「URL Rewriting」について簡単に解説します。
Cookie
Cookieは、セッション管理でいちばんよく用いられている手法です。
Webブラウザ側のコンピュータにテキストファイルとして保存できます。
また、Webブラウザを終了したときに、自動的にCookieを削除することもできます。
Cookieには、セッションIDのほか、関連する情報を含めることができます。
例えば、ショッピングサイトで選択された商品の情報をすべて含めることもできます。
しかし、セッション管理に必要な情報がすべてクライアントに渡されてしまうので、パフォーマンスが低下することもあります。
Cookieを使えない場合もあります。
Webブラウザ側でCookieの受入を拒否することができます。そうするとCookieは使えません。
URL Rewriting
Cookieが使えない環境の場合、代わりに使われる手法です。
セッションIDをURLに埋め込んで渡します。
例えば、Webサーバが生成するWebページに、次のようなリンクを含めます。
このidというパラメータがセッションIDです。
1 |
<a href='http://hogehoge.com/test/select?id=12345'>購入</a> |
Webブラウザ側でこのURLをクリックすると
1 |
http://hogehoge.com/test/select?id=12345 |
がWebサーバへの要求となります。これでセッション管理が可能になります。
しかし、この方法ではセッションIDがURL中に露出します。
そのため、セキュリティの面から見ると好ましくない方法です。
セッションの使用方法
セッションのライフサイクルについて
サーブレットにおけるセッション管理を実現するには、HttpSessionを使用します。
セッションの開始・継続・終了についてのコーディング方法を説明します。
一般的なシステムでは、まず初めにログイン認証処理が行われます。
次に買い物などの処理を行い、最後にログアウトが行われます。
この場合、ログイン認証処理が成功した直後に、セッションの開始となります。
次に買い物などを行う場合には、セッションの継続が必要となり、
最後にログアウトを行うときが、セッションの終了となります。
JSP内でセッションの使用を宣言する
1 |
<%@ page session="true"%> |
このJSPタグでセッションを使用することを宣言します。
もし、サーブレットやほかのページですでに開始されているセッションがあれば、そのセッションオブジェクトを使用します。
セッションがまだ開始されていなければ、ここで新たに開始しセッションオブジェクトも作成します。
- まだセッションを開始すべきでないページ=false
- セッション終了後のページ=false
- セッションは継続しているが、セッションオブジェクトを使用しないページ=false
- セッションが継続していて、セッションオブジェクトを使用するページ=true
セッションの開始方法
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
/** * ログイン画面で入力されたパスワードの整合性を判定するメソッド * @param aa ログイン画面の入力値を保存するform * @param result 入力値のバリデーション結果 * @param model ControllerからViewに値を受け渡すためのパラメータ * @return ログイン画面のJSPファイル名 or 勤務時間選択画面のJSPファイル名 */ @RequestMapping(value = "/loginProcess") public String loginProcess(HttpSession session, @ModelAttribute("loginForm") @Valid LoginForm aa, BindingResult result, Model model) { if (ログイン情報が正しい場合) { // セッションオブジェクトにログイン情報を詰める session.setAttribute("member", member); return 次の画面.jsp } else (ログイン情報が間違っている場合) { return ログイン画面.jsp } } |
通常上記のようにログイン情報入力後のメソッドで開始されることが一般的です。
①メソッドの引数にHttpSessionを記述します。
1 |
public String loginProcess(HttpSession session,,,,) |
②入力されたログイン情報が正しい場合に、セッションオブジェクトにログイン情報をアトリビュートします。
1 2 |
// セッションオブジェクトにログイン情報を詰める session.setAttribute(key名, ログイン情報); |
セッション情報を取得するとき
1 |
session.getAttribute(ログイン情報のkey名); |
アトリビュートして詰められたものは、getAttribute()を使って
ログイン情報のkey名を使って取得できます
セッションの継続・終了方法
継続方法は終了をしなければ継続できます。
ログアウトをするメソッドに下記の記述をします。
1 2 |
// セッションを終了させる session.invalidate(); |
1 |
session.removeAttribute("USER_INFO"); |
補足説明
セッションのタイムアウトについて
Webアプリケーションの場合は、ユーザーが処理の途中でブラウザを閉じる
ということもありますので、必ずしもログアウト処理が行われるとは限りません。
このような場合は、クライアント側は処理を終了しているのにもかかわらず、
サーバ側にはそのクライアントに対するセッション情報が残ってしまいます。
このように使用されなくなったセッション情報は、最後に使用されてからある一定時間が経過すると自動的に削除されます。
この時間をセッションタイムアウト時間といい、ユーザーが任意に設定することができます。
コメント