セッション管理のメカニズム

 


 


セッション管理のメカニズム

 

サーブレットAPIの仕様書は、特定のユーザからの一連の要求を互いに関連付けるメカニズムをHttpSessionというインターフェイスで提供している。サーブレット・エンジンは各クライアントに対応するHttpSessionのオブジェクトを簡単なデータベースで管理する。到来要求のセッションがこのデータベースに存在すればそのユーザはこのセッションに参加していると判断する。

 

HTTPはステートレスのプロトコルと言われる。要求と応答のセットで閉じてしまっており、おまけにHTTP/1.0ではTCPの接続も切断される。HTTP/1.1対応でないエンジンが主流であり、ブラウザも非対応のものが存在している限り、TCP接続はセッション管理には使えない。サーブレット仕様書(2.2)では、セッション管理のメカニズムとしてURL再書き込み(URL Rewriting)、クッキー(Cookies)、それにSSLセッションの使用を示している。

 

URL再書き込みはセッション管理として最小限エンジンが実装すべきもので、クッキーを受け付けないクライアントでも対応できる。URL再書き込みはURLパス情報にセッションのIDを付加するもので、例えば、

              http://www.myserver.co.jp/catalog/index.html;jsessionid=1234

のようなURLとなる。ここにセッションのパラメタ名はjsessionidである。

 

クッキーによるセッションのメカニズムも全てのサーブレット・エンジンに実装が要求されている。エンジンがクライアントに送ったクッキーを、クライアントはその後の要求にパラメタとして添付する。パラメタ名はJSESSIONIDと今度は大文字である。

 

SSLTCPとエンジンを含むアプリケーション層とのインターフェイスに置かれた暗号化とユーザ識別のメカニズムであり、これをサーブレット・エンジンはセッション管理に使うことができる。

 

使われているメカニズムはHttpSessionHttpSessionBindingListener及びHttpSessionContext(現在このインターフェイスは廃止されている)の3つのインターフェイスとHttpSessionBindingEventのクラスでプログラマからは一応遮蔽されているとはいえURL再書き込みはプログラマが関与しなければならない。使われているメカニズムと特性を把握しておくことは重要である。

 

以下にサーブレットにおけるセッションのメカニズムのイメージ(セキュリティは除く)を示す。我々はSimpleSessionTestというサーブレットを使ってこのイメージを確認していくことにする。

 


 


サーブレット・エンジンはHttpSessionのオブジェクトを管理する。サーブレットはgetSessioninvalidateのメソッドでこのオブジェクトの生成と削除をエンジンに依頼する。クライアントとのセッションの維持はSessionIdでなされる。このIDはサーブレットがこのコンテナ上で重複しないようエンジンが生成する。SessionId はクッキーやURL再書き込みを使ってクライアントとの間で交わされる。HttpSessionのオブジェクトは緑色で示すように幾つかのフィールドを持つ。サーブレットはAttributeというフィールドで複数のオブジェクトをバインドできる。オブジェクトがsessionにバインドされときあるいは、バインドから外されたときは、イベントでそのオブジェクトに通知できる。

 

イベントによる通知は非常に有用であり、タイムアウトによりサーブレット・エンジンがそのセッションが終了とみなして削除したことによる処理の開始や、各サーブレットのインスタンスのクライアント対応を統括するオブジェクトが各セッションの状況を把握したりするのに使うことができる。

 

 

前節     目次     次節