HTTP セッションは、セッション ID によって識別されます。 セッション ID は、実行時に生成される疑似乱数です。 セッション・アタックは HTTP セッションに対する既知のアタックで、ネットワークを経由するすべての要求 がセキュア接続 (すなわち HTTPS) を介するように強制することによって防ぐことができます。 しかし、そうすると SSL 接続のパフォーマンスが低下するため、カスタマー環境のすべての構成でこの制約が実行されているとは限りません。 このような緩やかな方式であるため、HTTP セッションはアタックを受けやすく、 このぜい弱性のために WebSphere Application Server では、HTTP セッション と WebSphere Application Server セキュリティーを緊密に統合するオプションが用意されています。 WebSphere Application Server でセキュリティーを使用可能にすると、 セッションへのアクセスが、そのセッションを作成したユーザーだけに許可されるという方法で保護されます。
HttpSession オブジェクトは、 HttpRequest の機能であり (req.getSession メソッドによってのみ取得可能)、 そのコピーはサーブレットまたは JSP ファイルの service メソッドの存続期間中のみ有効です。 HttpSession オブジェクトをキャッシュに入れて、 それをサーブレットまたは JSP ファイルの有効範囲外で参照することはできません。
クラスのシリアライズ可能性は、java.io.Serializable インターフェースを実装するクラスによって使用可能になります。 java.io.Serializable インターフェースを実装することにより、分散セッションの使用時に、オブジェクトはシリアライズされるようになります。 このインターフェースを実装しないクラスは、状態がシリアライズまたはデシリアライズされません。 このため、クラスがシリアライズ可能なインターフェースを実装しない場合、JVM はその状態をデータベースまたは別の JVM に保持できません。 シリアライズ可能なクラスのすべてのサブタイプはシリアライズ可能です。 次に例を挙げます。
public class MyObject implements java.io.Serializable {...}
transient とマークされていないインスタンス変数オブジェクトがすべてシリアライズ可能であることを確認してください。 シリアライズ可能でないオブジェクトをキャッシュすることはできません。
Java Servlet 仕様に準拠させるため、コンテナーがオブジェクトを格納するセッションのマイグレーションで必要なメカニズムをサポートできない場合は、分散サーブレット・コンテナーがオブジェクトの IllegalArgumentException を作成する必要があります。 例外が作成されるのは、分散可能を選択した場合だけです。
分散 HTTPSession サポートは、フェイルオーバー・シナリオの場合、 またはセッション類縁が中断している場合、属性のトランザクション保全性を保証するものではありません。 Enterprise Java Bean のような、トランザクションを配慮したリソースを使用して、 アプリケーションに必要なトランザクションの保全性を確保してください。
Java オブジェクトをセッションに追加する場合、 それらのオブジェクトのクラス・ファイルを正しいクラスパスに置くか (エンタープライズ・アプリケーションで複数の Web モジュール間での共用を利用する場合は アプリケーション・クラスパス、Servlet 2.2 準拠セッションの共用を使用 する場合は Web モジュール・クラスパス に置く)、あるいは、WebSphere Application Server で使用される他のサーブレットを含むディレクトリーに配置します。 セッションがクラスター化している場合、 このアクションはクラスター内のすべてのノードに適用されます。
HttpSession オブジェクトはユーザーがアクセスする可能性のあるサーブレット間で共用されるので、 競合を避けるために、サイト全体での統一された命名規則を設定することを検討してください。
ほとんどのアプリケーションでは、 各サーブレットが必要とするセッション・データは、全体のうちの一部のみです。 しかし、そのデータを単一のラージ・オブジェクトとして HttpSession オブジェクト内に保管すると、 アプリケーションは毎回 WebSphere Application Server にセッション・データの全体を強制的に処理させます。
WebSphere Application Server には、HTTP Server プラグイン内でセッション類縁性を支援する機能があります。 プラグインは、Cookie データ (またはエンコードされた URL) をブラウザーから読み取り、 割り当てられたセッション・キーに基づいて、該当するアプリケーションま たはクローンに要求を送信できるようにします。 この機能は、メモリー内のキャッシュの使用量を増加し、 データベースまたは別の WebSphere Application Server インスタンスへのヒット数を削減します。
セッション類縁を適切に使用すると、 WebSphere Application Server のパフォーマンスを高めることができます。 WebSphere Application Server 環境のセッション類縁性により、 セッション・オブジェクトのメモリー内キャッシュを最大化し、 データベースまたは別の WebSphere Application Server インスタンスへの読み込み回数を減らすことができます。 セッション類縁は、 ユーザーが対話しているアプリケーションのサーバー・インスタンス内のセッション・オブジェクトをキャッシュに入れることによって機能します。 アプリケーションが、あるサーバー・グループの複数のサーバーにデプロイされている場合、 アプリケーションはそれらのどのサーバーにもユーザーを誘導できます。 ユーザーがサーバー 1 から開始し、少し後でサーバー 2 に到達する場合、 サーバー 2 が稼働しているサーバー・インスタンスがデータベースを読み取れるように、 サーバーは、すべてのセッション情報を外部ロケーションに書き込む必要があります。 セッション類縁性を使用すると、このデータベース読み込みを回避できます。 セッション類縁性を用いて、ユーザーは最初の要求に対してサーバー 1 から開始し、 その後は、後続のすべての要求ごとに、サーバー 1 に戻されます。 サーバー 1 は、セッション情報を取得するためにキャッシュだけを調べればよく、 情報を取得するためにセッション・データベースを呼び出す必要がなくなります。
セキュリティーとセッションに関しては、すべてを保護するか、まったく保護しないかのいずれかです。 一部の時間だけセッション状態へのアクセスを保護するのは無意味です。 セッション管理機構でセキュリティー統合が使用可能になっている場合、 セッションの作成元またはアクセス元となるすべてのリソースは、保護か非保護かのいずれかでなければなりません。 保護されているリソースと保護されていないリソースを混在させることはできません。
数ページしか保護しない場合の問題点は、 保護ページで作成されたセッションが許可ユーザーの ID の下に作成されるということです。 他の保護ページ内のこれらのセッションにアクセスできるのは、同じユーザーだけです。 非許可ユーザーによるこれらのセッションの使用を防ぐため、 非保護ページからこれらのセッションにアクセスすることはできません。 非保護ページから要求が出されると、 アクセスは拒否され、UnauthorizedSessionRequestException エラーが作成されます。 (UnauthorizedSessionRequestException はランタイム例外であり、ログに記録されます。)
アプリケーションがセッションを使用している場合、 そのセッションに対するデータの読み取りや書き込みが行われるたびに、書き込み頻度として END_OF_SERVICE を使用して、 LastAccess 時間フィールドは更新されます。 データベース・セッションが使用される場合、 そのデータベースへの新規書き込みが行われます。 このアクティビティーは、パフォーマンスに対するヒットであり、「 手動更新」オプションを使用したり、レコードの読み取りや書き取りのたびにではなく、 データ値が更新された場合に限りレコードをデータベースに書き戻したりすることによって回避できます。
手動更新を使用するには、セッション管理サービスでそれをオンにします。 (ロケーション情報については、上記の表を参照してください。) さらに、アプリケーション・コードは、 汎用 HttpSession ではなく com.ibm.websphere.servlet.session.IBMSession クラスを使用する必要があります。 IBMSession オブジェクトには sync メソッドがあります。このメソッドは、 セッション・オブジェクト内のデータをデータベースに書き込むよう WebSphere Application Server に伝えます。 このアクティビティーにより、開発者は、必要な場合に限りセッション情報を持続させることによって、 パフォーマンスを全体的に向上させることができます。