デフォルトでは、tomcatは現在のドメインのセッションCookieを作成します。
www.example.comを使用している場合、Cookieはwww.example.com用に作成されます（www.example.comでのみ機能します）。たとえば、example.comは.example.com用に作成されます（望ましい動作は、example.com自体だけでなくexample.comの任意のサブドメインでも機能します）。
セッションCookieの作成をインターセプトし、正しい.example.comドメインで置換Cookieを作成するように見えるTomcatバルブをいくつか見ましたが、どれも問題なく機能しているようには見えず、すべて既存のCookieを残しているように見えます。新しいものを作成します。これは、リクエストごとに2つのJSESSIONIDCookieが送信されていることを意味します。
誰かがこの問題の決定的な解決策を持っているかどうか疑問に思いました。
これは、6.0.27 以降の構成設定を介して明らかにサポートされています。
構成は、META-INF/context.xml を編集して行います。
<Context sessionCookiePath="/something" sessionCookieDomain=".domain.tld" />
簡単な解決策を探して、これらすべてを実行しました。私は最初にTomcatの観点からそれを見始めました。
Tomcatは、セッションのドメインCookieを構成するための直接アクセスを提供しません。また、他のいくつかの投稿に示されているように、tomcatにカスタムパッチを適用してその問題を修正したくありませんでした。
サーブレット仕様に組み込まれているヘッダーとCookieへのアクセスに制限があるため、Tomcatのバルブも問題の解決策のようです。http応答がバルブに渡される前にコミットされた場合も、完全に失敗します。
Apacheを介してリクエストをプロキシするため、代わりにapacheを使用して問題を修正する方法に移りました。
最初にmod_proxyディレクティブProxyPassReverseCookieDomainを試しましたが、Tomcatがドメイン属性を設定せず、ProxyPassReverseCookieDomainは、Cookieの一部である何らかのドメインがないと機能しないため、JSESSIONIDCookieでは機能しません。
また、ProxyPassReverseCookiePathを使用して、Cookieにドメイン属性を追加するためにパスを書き換えるハックに遭遇しましたが、それは本番サイトにとって厄介な方法だと感じました。
上記のDaveが述べたように、apacheのmod_headersモジュールを使用して応答ヘッダーを書き直すことで、ようやく機能するようになりました。
仮想ホスト定義内に次の行を追加しました。
Header edit Set-Cookie "(JSESSIONID\s?=[^;,]+?)((?:;\s?(?:(?i)Comment|Max-Age|Path|Version|Secure)[^;,]*?)*)(;\s?(?:(?i)Domain\s?=)[^;,]+?)?((?:;\s?(?:(?i)Comment|Max-Age|Path|Version|Secure)[^;,]*?)*)(,|$)" "$1$2; Domain=.example.com$4$5"
上記はすべて、構成内の1行である必要があります。これにより、JSESSIONIDCookieドメイン属性が「.example.com」に置き換えられます。JSESSIONID Cookieにドメイン属性が含まれていない場合、パターンは「.example.com」の値を持つドメイン属性を追加します。ボーナスとして、このソリューションは、バルブの二重JSESSIONCookieの問題に悩まされることはありません。
このパターンは、ヘッダー内の他のCookieに影響を与えることなく、Set-Cookieヘッダー内の複数のCookieで機能する必要があります。また、パターンの最初の部分のJSESSIONIDを任意のCookie名に変更することにより、他のCookieを操作するように変更できる必要があります。
私は正規表現のパワーユーザーではないので、パターンに対していくつかの最適化を行うことができると確信していますが、これまでのところうまく機能しているようです。
パターンにバグが見つかった場合は、この投稿を更新します。うまくいけば、これにより、私が行ったように、ここ数日分の欲求不満を経験する必要がなくなるでしょう。
$DAYJOB でこれに遭遇しました。私の場合、SSLサインオンを実装してから非SSLページにリダイレクトしたかったのです。tomcat の中心的な問題は、アクセスしたいすべての変数をハードコードする (メモリからの) SessionManager.configureSessionCookie メソッドです。
私は、正規表現置換に基づいて Cookie を書き換えるために apache で mod_headers を使用する特に悪質なハックを含む、いくつかのアイデアを思いつきました。
これを解決する決定的な方法は、SessionManager クラスに構成可能なパラメーターを追加するパッチを tomcat 開発者に送信することです。
セッション (およびその ID) は基本的に、発行元のアプリケーションに対してのみ価値があると見なされるため、追加の Cookie を設定することをお勧めします。Tomcats SingleSignOnValve を見て、"/applicationName" の代わりにサーバー パス "/" に追加の Cookie JSESSIONIDSSO (...SSO に注意) を提供します (JSESSIONID Cookie は通常設定されるため)。
このような Valve を使用すると、さまざまなサーバー、仮想ホスト、または任意の数の Tomcat/Web サーバーなどの Web アプリケーション間で状態を同期するために必要なプロセス間通信を実装できます。
Tomcats セッション Cookie を独自の目的で使用できないもう 1 つの理由は、同じホスト上の複数の Web アプリケーションが異なるセッション ID を持っていることです。たとえば、「/webapp1」と「/webapp2」には異なる Cookie があります。「/webapp1」の Cookie を「/webapp2」に提供すると、参照したセッションが見つからず、セッション + Cookie が無効になり、独自の新しい Cookie が設定されます。外部セッション ID 値を受け入れる (セキュリティ的には悪い考えです) か、アプリケーション間で特定の状態を共有するには、すべての tomcats セッション処理を書き直す必要があります。
セッション処理は、コンテナー (Tomcat) ビジネスと見なす必要があります。他に必要なものは何でも、コンテナが実行する必要があると信じていることを妨げずに追加する必要があります。