HTTP セッションの問題

Hypertext Transfer Protocol (HTTP) セッションを作成または使用するときの問題に関するトラブルシューティング情報を使用します。

ここで説明するセッション・マネージャーの設定を表示および更新するには、管理コンソールを使用します。 問題のアプリケーションがホスティングされているアプリケーション・サーバーを選択し、「追加プロパティー」の下の「Web コンテナー」を選択して、次に「セッション・マネージャー」を選択します。

[AIX Solaris HP-UX Linux Windows][IBM i]該当する問題がここで説明されていないか、またはこれらのステップで問題が修正できない場合は、以下を行ってください。

HTTP セッションが作成されないか、または要求と要求の間に失われる

デフォルトでは、セッション・マネージャーは Cookie を使用して、要求と要求の間にクライアントにセッション ID を保管します。 Cookies ベースのセッション・トラッキングを回避する場合をのぞき、Cookies が WebSphere Application Server とブラウザーの間を流れていることを以下のように確認します。
  • 「セッション・トラッキング・メカニズム」プロパティーの下の「Cookie を使用可能にする」チェック・ボックスにチェックマークを付けてください。
  • テストを実施するブラウザー、またはユーザーがアプリケーションにアクセスしているブラウザーで Cookies が使用可能になっていることを確認します。
  • 「SessionManager」で指定されている Cookie ドメインをチェックします (Cookie の設定を表示または更新する場合は、「セッション・トラッキング・メカニズム」 > 「Cookie を使用可能にする」プロパティーで、「変更」をクリックします)。
    • 例えば、Cookie ドメインが「.myCom.com」と設定されている場合、そのドメイン・ネームを使用してリソースにアクセスする必要があります。例: http://www.myCom.com/myapp/servlet/sessionservlet
    • ドメイン・プロパティーが設定されている場合は、それがドット (.) で始まっていることを確認してください。. Netscape のバージョンによっては、ドメイン・ネームがドットで始まっていないと Cookies を受け付けない場合があります。Internet Explorer は、ドットがあってもドットがなくてもそのドメインを受け入れます。例えば、ドメイン・ネームが mycom.com に設定されている場合は、それを .mycom.com に変更します。これにより、Netscape も Internet Explorer も Cookie を受け入れます。
      注: サーバーが別のホスト上にある場合は、プラグインを使用している、または Cookie ドメインを設定している Web サーバーなどのフロントエンド・ルーターを構成することにより、セッション Cookie がすべてのサーバーに流れるようにします。
  • 「SessionManager」で指定されている「Cookie パス」をチェックします。問題の URL が、指定された Cookie パスよりも階層的に下になっていることをチェックしてください。このようになっていない場合は、Cookie パスを訂正します。
  • Cookie maximum age プロパティーが設定されている場合は、クライアント (ブラウザー) マシンの日付と時刻が、時間帯を含めてサーバーの日付と時刻と同じであることを確認します。クライアントとサーバーの時間の差が「Cookie 最大経過時間」よりも大きい場合、Cookie はアクセス後に期限切れになるため、アクセスはすべて新規セッションになります。
  • エンタープライズ・アプリケーション内にセッションを追跡する複数の Web モジュールがある場合は、以下のようにします。
    • エンタープライズ・アプリケーション内の各 Web モジュールで異なるセッションの設定を使用する場合は、各 Web モジュールで異なる Cookie 名またはパスを指定するようにします。
    • エンタープライズ・アプリケーション内の Web モジュールが共通の Cookie 名とパスを使用している場合は、"Cookie の最大経過時間"などの HTTP セッションの設定がすべての Web モジュールで同じになるようにしてください。これを行わないと、Cookie の振る舞いは予測不能となり、セッションを作成するアプリケーションに左右されます。 このことは、セッション・データには影響を与えないことに注意してください。セッション・データは、Web モジュールによって個別に保守されています。
  • 以下のようにして、ブラウザーとサーバーの間の Cookie の流れをチェックします。
    1. ブラウザーで「Cookie プロンプト」を使用可能にします。サーブレットをヒットし、Cookie が要求されることを確認します。
    2. [AIX Solaris HP-UX Linux Windows][IBM i]サーバーで SessionManager のトレースを使用可能にします。トレース指定「com.ibm.ws.session.*=all=enabled」を使用して、HTTP セッション・マネージャー・コンポーネントに対してトレースを使用可能にします。トレースを使用可能にした後、セッションを使用するサーブレットまたは JSP を実行し、指示に従ってトレース出力をダンプして参照します。
    3. ブラウザーからセッション・サーブレットにアクセスします。
    4. ブラウザーは Cookie を要求します。jsessionid をメモしておいてください。
    5. サーブレットを再ロードし、新規の Cookie が送信されてきた場合は、前の Cookie を書き留めておきます。
    6. セッション・トレースをチェックして、セッション ID を探し、スレッドにより要求をトレースします。以下のようにして、Web 要求の間でセッションが継続していることを確認します。
      • セッション要求の開始である getIHttpsession(...) を探します。
      • サーブレット要求の終わりである releaseSession(..) を探します。
  • Cookies ではなく URL の再書き込みを使用している場合は、以下のようにします。
    • アプリケーションのナビゲーション・パスに静的な HTML ページが存在していないことを確認します。
    • [AIX Solaris HP-UX Linux Windows][IBM i]サーブレットおよび JSP ファイルが URL の再書き込みを正しく実装していることを確認します。 詳細および例については、セッション・トラッキング・オプションを参照してください。
  • 非推奨の機能 (Deprecated feature) 非推奨の機能 (Deprecated feature): SSL ID を使用したセッションのトラッキングは、 WebSphere Application Server バージョン 7.0 では推奨されません。 セッション・トラッキングを構成して Cookie を使用するか、あるいはアプリケーションを変更して、URL 再書き込みを使用することができます。depfeat
    SSL をセッション・トラッキング・メカニズムとして使用している場合は、以下のようにしてください。
  • クラスター (複数のノード) 環境の場合は、セッション・パーシスタンスが使用可能になっていることを確認します。

HTTP セッションがパーシスタントでない

HTTP セッションがパーシスタントでない場合は、アプリケーション・サーバーの再始動時にセッション・データが失われたか、またはこのデータがクラスター間で共有されていません。
  • データ・ソースを確認します。
  • セッション・マネージャーのパーシスタンス設定のプロパティーをチェックします。
    • セッション・パーシスタンスを使用したい場合は、 「パーシスタンス」が「データベース」に設定されていることを確認します。
    • [AIX Solaris HP-UX Linux Windows][IBM i]パーシスタンスを「メモリー間の複製」に設定することもできます。
    • データベース・ベースのパーシスタンスを使用している場合は、以下のようにします。
      • データ・ソースの JNDI 名が SessionManager に正しく設定されているかどうかを確認します。
      • データベースにアクセスするための正しいユーザー ID とパスワードを指定します。

        これらの設定では、管理コンソールで既存のデータ・ソースのプロパティーと照合する必要があることに注意してください。 セッション・マネージャーでは、セッション・データベースが自動的に作成されません。

      • データ・ソースは、非 JTA、例えば 非 XA 対応である必要があります。
      • [AIX Solaris HP-UX Linux Windows][IBM i]JVM ログで該当するデータベース・エラー・メッセージを確認します。
      • [z/OS]ログで該当するデータベース・エラー・メッセージを確認します。
      • DB2® では、4k 以外の行サイズについて、指定された行サイズが DB2 のページ・サイズに一致するかどうかを確認します。 表スペース名が正しく指定されていることを確認します。
    • メモリー・ベースのパーシスタンス (Network Deployment 環境でのみ使用可能) を使用している場合は、以下のようにします。
      • メモリー間の複製を参照してください
      • セッション・マネージャーの内部複製ドメインのプロパティーを確認してください。

同一のクライアント・マシン上の複数のブラウザーでセッションが共有される

この振る舞いは、ブラウザーに依存します。 ブラウザーの動作は、ブラウザーのベンダーによって異なります。 また、ブラウザーが新規のプロセスとして起動されるか、または既存のブラウザー・セッションのサブプロセスとして起動される (例えば、Windows の場合は Ctl-N を押す、など) かに応じて変化する場合があります。

Cookie がセッション・トラッキング・メカニズムとして使用されている場合は、セッション・マネージャーの Cookie の最大経過時間プロパティーもこの振る舞いに影響を与えます。 最大経過時間が正の値に設定されている場合、すべてのブラウザー・インスタンスで Cookies が共有されます。Cookie は、指定された最大経過時間の間、クライアント側のファイルで永続化されます。

指定されたセッションのタイムアウト間隔の経過後、セッションが即時に無効にならない

SessionManager の無効化プロセスのスレッドは x 秒ごとに実行され、無効なセッションを無効化します。この場合、x は、セッション・マネージャーのプロパティーで指定されたセッション・タイムアウト間隔に基づいて決定されます。 デフォルト値が 30 分の場合は、x はおよそ 300 秒になります。この場合は、特定のセッションが無効化されるまでに、30 分のタイムアウトしきい値を超えてから最大 5 分 (300 秒) かかります。

不要なセッションが JavaServer Pages によって作成される

JavaServer Pages (JSP) 仕様によって、JSP ページは、デフォルトでは request.getSession(true) を実行します。その結果、そのクライアントにセッションが存在していない場合はセッションが作成されます。 JSP ページが新規のセッションを作成することを防ぐには、以下のようにページ・ディレクティブを使用して、.jsp ファイルのセッションの有効範囲を false に設定します。
<% @page session="false" %>
[AIX Solaris HP-UX Linux Windows][IBM i]

1 つのクライアント用のセッション・データが、別のクライアントにも表示される

まれに、アプリケーション・エラーが原因で、1 つのクライアント用のセッション・データが別のクライアントにも表示されることがあります。 この状態は、セッション・データ・クロスオーバーと呼ばれます。 DebugSessionCrossover カスタム・プロパティーが true に設定されていると、セッション・データ・クロスオーバーのインスタンスを検出し、記録するのにコードを使用できます。 要求に関連するセッションのみがアクセスされるか、または参照されていることを確認するために検査が実行されます。 矛盾が検出されると、メッセージがログに記録されます。 これらのメッセージを使用して、この問題のデバッグを開始します。 この追加チェックは、ユーザーが作成したスレッドではなく、WebSphere 管理のディスパッチ・スレッドで 実行されている場合にのみ行われます。

このプロパティーの設定方法についての追加情報は、 Web コンテナーのカスタム・プロパティーの項目を参照してください。

HTTP セッションのタイマーが 期限切れになると、ユーザーがログアウトされない

WebSphere Application Server の ユーザーがアプリケーションにログオンし、指定された HTTP セッション・タイムアウト値より長い時間アイドル状態であった場合、ユーザー情報は無効にならず、LTPA トークンがタイムアウトになるまで ユーザー・クレデンシャルはアクティブのままです。

PK25740 の適用後、以下のステップを実行すると、HTTP セッションが期限切れとなった後にユーザーをアプリケーションからログアウトさせることができます。
重要: com.ibm.ws.security.web.logoutOnHTTPSessionExpire プロパティーは、フォーム・ログインを使用するアプリケーションにのみ適用されます。
  1. 管理コンソールで、「セキュリティー」>「グローバル・セキュリティー」とクリックします。
  2. 「カスタム・プロパティー」の下で、「新規」をクリックします。
  3. 「名前」フィールドに、com.ibm.ws.security.web.logoutOnHTTPSessionExpire と入力します。
  4. 「値」フィールドに true と入力します。
  5. 「適用」および「保存」をクリックして、構成の変更を保存します。
  6. サーバーを再同期して再始動します。
予期しない再認証: com.ibm.ws.security.web.logoutOnHTTPSessionExpire カスタム・プロパティーを true に設定すると、複数の Web アプリケーションを操作しているときに予期しない再認証が発生することがあります。デフォルトでは、各 Web アプリケーションには独自の HTTP セッションがありますが、Web ブラウザーが持っているのは 1 つのセッション Cookie です。この問題に対処するには、固有のセッション Cookie 名またはパス設定をアプリケーションそれぞれに与えることによって、HTTP セッション構成を変更できます。 その結果、各アプリケーションは独自のセッション Cookieを持ちます。または、同じ HTTP セッションを共有するよう、同じエンタープライズ・アプリケーションで複数の Web アプリケーションを構成できます。詳しくは、トピック『セッション・データを共有可能にするアセンブル』の説明を参照してください。

セッション・パーシスタンスが有効になっている場合にアプリケーションを更新すると、実行時に例外が発生することがある

実行時にセッション・パーシスタンスを有効にしてアプリケーション更新を実行するユーザーは、アプリケーションの再始動後に予期しない例外を受け取ることがあります。

保存されている属性を変更するような更新が行われた場合、関連するアプリケーションがそれらの変更を処理できないのであれば、 そのアプリケーションによって作成されたすべてのセッションをアプリケーション更新よりも前に無効にしなければならない可能性があります。 この場合、すべてのセッション・オブジェクトをバックエンドからも削除する必要があります。 これらのセッションを適切に削除する方法について詳しくは、『HTTP セッションの無効化』のトピックを参照してください。

IBM サポートが提供する資料とツールを利用すれば、 問題解決に必要な情報を集める時間を節約できます。 問題報告書を開く前に、以下のサポート・ページを参照してください。

トピックのタイプを示すアイコン 参照トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_httpsessprobs
ファイル名:rtrb_httpsessprobs.html