デフォルトでは、Tomcatは現在のドメインのセッションCookieを作成します。Tomcatを使用してサブドメインのセッションCookieを有効にする最良の方法
www.example.comにアクセスしている場合、www.example.com用にCookieが作成されます（www.example.com上でのみ動作します）。 example.comの場合は.example.com用に作成されます（希望の動作はexample.comのサブドメインとexample.com自体で動作します）。
セッションクッキーの作成を傍受し、正しい.example.comドメインを持つ置換クッキーを作成するようなTomcatバルブがいくつか見受けられますが、どれも完璧に機能していないようです。既存のCookieを作成して新しいCookieを作成するだけです。つまり、リクエストごとに2つのJSESSIONID Cookieが送信されます。
誰かがこの問題の決定的な解決策を持っているのだろうかと思いました。
これは6.0の設定で明らかにサポートされています。27以降：
"domain.tldに。"設定が META-INF/context.xmlに
<コンテキスト sessionCookiePath = "/何か" を編集することによって行われ sessionCookieDomain =/>
これは$ DAYJOBで実行されました。私の場合は、SSLサインオンを実装して、SSL以外のページにリダイレクトしたかったのです。 Tomcatの中核となる問題は、（メモリからの）SessionManager.configureSessionCookieメソッドで、アクセスしたいすべての変数をハードコードします。
私はいくつかのアイデアを思いつきました。特に、Apacheのmod_headersを使って、正規表現の置き換えに基づいてCookieを書き直すという面白いハッキングがありました。
これを解決する決定的な方法は、設定可能なパラメータをSessionManagerクラスに追加するTomcat開発者にパッチを提出することです。
セッション（とそのId）は、基本的に発行しているアプリケーションでのみ価値があるとみなされるため、追加のCookieを設定することができます。 TomcatのSingleSignOnValveを見て、 "/ applicationName"の代わりにサーバーパス "/"（JSESSIONID Cookieが通常設定されているため）の代わりにCookie JSESSIONIDSSO（SSOに注意してください）を指定してください。
このようなバルブを使用すると、任意の数のtomcats/webservers/otherの異なるサーバー、仮想ホスト、またはWebアプリケーション間の状態を同期させるために必要なプロセス間通信を実装できます。
tomcatsセッションCookieを自分の目的に使用できないもう一つの理由は、同じホスト上の複数のWebアプリケーションが異なるセッションIDを持つことです。例えば。 "/ webapp1"と "/ webapp2"には異なるクッキーがあります。 "/ webapp1"のクッキーを "/ webapp2"に指定すると、参照したセッションが見つからず、セッション+クッキーが無効になり、新しいものが設定されます。外部セッションID値を受け入れるか（セキュリティを悪意のある考え方）、アプリケーション間で特定の状態を共有するために、すべてのtomcatsセッション処理を書き直す必要があります。
セッション処理は、コンテナ（tomcats）ビジネスとみなす必要があります。あなたが必要とするものがあれば、容器が必要と考えるものを妨げずに追加する必要があります。
バルブ技術は100％完全ではないようです。もしあなたがTomcat自体を変更するつもりなら：
catalina.jarは、次のクラスを含んでいます：org.apache.catalina.connector。リクエスト
は、要求メソッドがあります。
configureSessionCookie(Cookie cookie)
は、私たちの環境のために、それはちょうどそれをハードコーディングするのが最善だったが、あなたはより多くの空想のロジックを行うことができます：
cookie.setDomain(".xyz.com");
は完璧に動作するようです。これがtomcatで設定可能であればいいでしょう。
私はこのすべてを単純な解決策を探しています。私は最初にTomcatの視点から見始めた。
Tomcatは、セッションのためのドメインクッキーの設定に直接アクセスすることはできません。他のいくつかのポストに示されているように、問題を修正するためにTomcatをカスタムパッチすることは間違いありません。
サーブレット仕様に組み込まれているクッキー&にアクセスする際の制限により、Tomcatのバルブも問題解決のようです。また、HTTP応答がコミットされてからバルブに渡されると、それらは完全に失敗します。
私たちはApacheを通してリクエストをプロキシするので、代わりにApacheを使用して問題を解決する方法に移りました。
私は最初にmod_proxyディレクティブのProxyPassReverseCookieDomainを試しましたが、tomcatがドメイン属性を設定していないため、Cookieの一部であるドメインがないとProxyPassReverseCookieDomainが動作しないため、JSESSIONID Cookieでは機能しません。
また、ProxyPassReverseCookiePathを使用してハックしたところで、ドメイン属性をクッキーに追加するためのパスを書き換えていましたが、これは本番サイトでは厄介なものでした。
私はついに、上記の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"
は、上記のすべての設定では、単一の行でなければなりません。 JSESSIONIDクッキーのドメイン属性を ".example.com"に置き換えます。 JSESSIONIDクッキーにドメイン属性が含まれていない場合、パターンは ".example.com"の値を持つパターンを追加します。ボーナスとして、このソリューションは弁の二重JSESSIONクッキーの問題に悩まされません。
パターンは、ヘッダーの他のCookieに影響を与えずに、Set-Cookieヘッダーの複数のCookieで機能するはずです。また、パターンの最初の部分のJSESSIONIDを、あなたが望むクッキー名に変更することによって、他のクッキーと連携するように変更する必要があります。
私はreg-exパワーユーザーではないので、パターンにできる最適化がいくつかあると確信していますが、これまでのところ私たちのために働いているようです。
パターンにバグがある場合は、この投稿を更新します。うまくいけば、これは、私がしたように、最後の数日間の欲求不満を経験することをやめることから、あなたのうちのいくつかを止めるでしょう。
+1ちょうど私が探していたもの！最後に、パッチが含まれていました。 – Kdeveloper