Tomcat を使用してサブドメイン セッション Cookie を許可する最良の方法
https://stackoverflow.com/questions/82645
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
デフォルトでは、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 つの JSESSIONID Cookie が送信されることを意味します。
誰かがこの問題に対する決定的な解決策を持っているのだろうかと疑問に思いました。
解決
これは、6.0.27 以降の構成設定によってサポートされているようです。
構成は、meta-inf/context.xmlの編集によって行われます
u003CContextn sessionCookiePath="/something"n sessionCookieDomain=".domain.tld" />
他のヒント
私は簡単な解決策を探してこれらすべてを経験しました。私は最初に Tomcat の観点からそれを見始めました。
Tomcat はセッションのドメイン Cookie を構成するための直接アクセスを提供しません。また、他の投稿で示されているように、この問題を修正するために Tomcat にカスタム パッチを適用することは絶対に望んでいませんでした。
Tomcat のバルブも、サーブレット仕様に組み込まれているヘッダーと Cookie へのアクセス制限のため、問題解決策であるようです。また、http 応答がバルブに渡される前にコミットされた場合も完全に失敗します。
私たちは Apache を介してリクエストをプロキシしているため、代わりに Apache を使用して問題を解決する方法に移りました。
最初に mod_proxy ディレクティブ ProxyPassReverseCookieDomain を試しましたが、Tomcat はドメイン属性を設定せず、ProxyPassReverseCookieDomain は Cookie の一部である何らかのドメインがないと機能しないため、JSESSIONID Cookie に対しては機能しませんでした。
また、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 行である必要があります。これにより、JSESSIONID Cookie ドメイン属性が「.example.com」に置き換えられます。JSESSIONID Cookie にドメイン属性が含まれていない場合、パターンは値「.example.com」を持つドメイン属性を追加します。おまけに、このソリューションはバルブの二重 JSESSION Cookie の問題に悩まされません。
このパターンは、ヘッダー内の他の Cookie に影響を与えることなく、Set-Cookie ヘッダー内の複数の Cookie で機能する必要があります。また、パターンの最初の部分にある JSESSIONID を任意の Cookie 名に変更することで、他の Cookie を操作できるように変更可能である必要があります。
私は正規表現のパワーユーザーではないので、パターンに対していくつかの最適化ができると思いますが、今のところうまく機能しているようです。
パターンにバグが見つかった場合は、この投稿を更新します。これで、私と同じように、ここ数日相当のフラストレーションを経験する人が少なくなることを願っています。
$DAYJOB でこれに遭遇しました。私の場合は、SSL サインオンを実装してから、非 SSL ページにリダイレクトしたいと考えていました。Tomcat の中心的な問題は、アクセスしたいすべての変数をハードコードする (メモリからの) SessionManager.configureSessionCookie メソッドです。
私はいくつかのアイデアを思いつきました。その中には、Apache の mod_headers を使用して正規表現の置換に基づいて Cookie を書き換える、特にひどいハックが含まれます。
これを解決する最終的な方法は、設定可能なパラメータを SessionManager クラスに追加するパッチを Tomcat 開発者に提出することです。
セッション (およびその ID) は基本的に、発行アプリケーションに対してのみ価値があると考えられるため、追加の Cookie の設定を検討することをお勧めします。Tomcats SingleSignOnValve を見てください。(通常は JSESSIONID Cookie が設定されるため) "/applicationName" ではなく、サーバー パス "/" に追加の Cookie JSESSIONIDSSO (...SSO に注意してください) を提供します。
このような Valve を使用すると、さまざまなサーバー、仮想ホスト、または任意の数の Tomcat/Web サーバーなどの Web アプリケーションの間で状態を同期するために必要なプロセス間通信を実装できます。
Tomcats セッション Cookie を独自の目的で使用できないもう 1 つの理由は、同じホスト上の複数の Web アプリが異なるセッション ID を持っていることです。例えば。「/webapp1」と「/webapp2」には異なる Cookie があります。「/webapp1」の Cookie を「/webapp2」に提供すると、参照したセッションが見つからず、セッションと Cookie が無効になり、独自の新しいセッションが設定されます。外部セッション ID 値を受け入れるか (セキュリティ上悪い考えです)、アプリケーション間で特定の状態を共有するには、Tomcat のセッション処理をすべて書き直す必要があります。
セッション処理はコンテナー (Tomcat) ビジネスとして考慮する必要があります。他に必要なものは何でも、コンテナが実行する必要があると判断することを妨げずに追加する必要があります。
バルブ技術は 100% 完璧ではないようです。Tomcat 自体を変更する勇気がある場合:
カタリナ.jar 次のクラスが含まれています。 org.apache.catalina.connector.Request
リクエストには次のメソッドがあります。
configureSessionCookie(Cookie cookie)
私たちの環境では、単にハードコーディングするのが最善でしたが、より複雑なロジックを実行することもできます。
cookie.setDomain(".xyz.com");
完璧に動作しているようです。これがTomcatで設定可能であれば良いのですが。
