Tomcatを使用してサブドメインセッションCookieを許可するための最良の方法
デフォルトでは、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にカスタムパッチを適用してその問題を修正したくありませんでした。
Tomcatのバルブも、サーブレット仕様に組み込まれているヘッダーとCookieへのアクセスに制限があるため、問題の解決策のようです。また、Valveに渡される前に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です。
Apacheでmod_headersを使用して正規表現の置換に基づいてCookieを書き換える、特にひどいハッキングなど、いくつかのアイデアを思いつきました。
これを解決する最も確実な方法は、Tomcat開発者にパッチを送信して、SessionManagerクラスに構成可能なパラメーターを追加することです。
セッション（およびそのID）は基本的に、発行するアプリケーションに対してのみ価値があると見なされるため、追加のCookieの設定を探すことをお勧めします。 TomcatのSingleSignOnValveを見て、「/ applicationName」の代わりにサーバーパス「/」に追加のCookie JSESSIONIDSSO（... SSOに注意）を提供します（JSESSIONID Cookieが通常設定されるため）。
このようなValveを使用すると、さまざまなサーバー、仮想ホスト、または任意の数のtomcat/webserversなどのWebアプリケーション間で任意の状態を同期するために必要なプロセス間通信を実装できます。
独自の目的でtomcatsセッションCookieを使用できないもう1つの理由は、同じホスト上の複数のWebアプリケーションのセッションIDが異なるためです。例えば。 「/ webapp1」と「/ webapp2」には異なるCookieがあります。 「/ webapp1」のCookieを「/ webapp2」に指定すると、参照したセッションが見つからず、session + cookieが無効になり、独自の新しいCookieが設定されます。外部セッションID値を受け入れる（セキュリティ的には悪い考えです）か、アプリケーション間で特定の状態を共有するには、すべてのtomcatsセッション処理を書き直す必要があります。
セッション処理は、コンテナー（tomcats）ビジネスと見なす必要があります。他に必要なものは何でも、コンテナが実行する必要があると信じていることを妨げることなく追加する必要があります。
バルブ技術は100％完璧ではないようです。 Tomcat自体をあえて変更する場合：
catalina.jar次のクラスが含まれています：org.Apache.catalina.connector.Request
リクエストには次のメソッドがあります。
configureSessionCookie(Cookie cookie)
私たちの環境では、ハードコーディングするのが最善でしたが、もっと凝ったロジックを実行することもできます。
cookie.setDomain(".xyz.com");
完全に機能しているようです。これがTomcatで構成可能であれば、すばらしいでしょう。