Die beste Methode, um Subdomänensitzungscookies mit Tomcat zuzulassen

Question

Standardmäßig erstellt tomcat einen Sitzungscookie für die aktuelle Domäne.

Wenn Sie sich auf www.example.com befinden, wird Ihr Cookie für www.example.com erstellt (funktioniert nur auf www.example.com). Während für example.com.com zum Beispiel für .example.com erstellt wird (gewünschtes Verhalten, funktioniert bei jeder Subdomain von example.com genauso wie bei example.com selbst).

Ich habe ein paar Tomcat - Ventile gesehen, die die Erstellung von Session - Cookies abfangen und einen Ersatz - Cookie mit der korrekten .example.com - Domain erstellen, aber keiner von ihnen scheint fehlerfrei zu funktionieren und sie scheinen alle zu verlassen existierender Cookie und erstellen Sie einfach einen neuen. Dies bedeutet, dass mit jeder Anfrage zwei JSESSIONID-Cookies gesendet werden.

Ich frage mich, ob jemand eine endgültige Lösung für dieses Problem hat.

Answer 1

Dies wird anscheinend über eine Konfigurationseinstellung in 6.0 unterstützt.27 und weiter:

Konfiguration wird durch die Bearbeitung META-INF/context.xml

< Kontext getan sessionCookiePath = "/ etwas" sessionCookieDomain =/>

"domain.tld."

https://issues.apache.org/bugzilla/show_bug.cgi?id=48379

Answer 2

Ich habe in diesem bei $ DAYJOB geführt. In meinem Fall wollte ich SSL-Signon implementieren und dann auf eine Nicht-SSL-Seite umleiten. Das Kernproblem in Tomcat ist die Methode (aus dem Speicher) SessionManager.configureSessionCookie, die alle Variablen fest codiert, auf die Sie zugreifen möchten.

Ich kam mit ein paar Ideen, einschließlich einer besonders ungeheuerlichen Hack mit mod_headers in Apache, um das Cookie basierend auf Regex-Substitution neu zu schreiben.

Der definitive Weg, dies zu lösen, wäre, einen Patch an die Tomcat-Entwickler zu senden, der der SessionManager-Klasse konfigurierbare Parameter hinzufügt.

Answer 3

Da eine Sitzung (und ihre ID) grundsätzlich nur für die ausstellende Anwendung von Wert ist, können Sie lieber nach einem zusätzlichen Cookie suchen. Werfen Sie einen Blick auf Tomcats SingleSignOnValve und stellen Sie den zusätzlichen Cookie JSESSIONIDSSO (beachten Sie den ... SSO) für den Serverpfad "/" anstelle von "/ applicationName" bereit (da JSESSIONID-Cookies normalerweise gesetzt sind).

Mit solch einem Valve können Sie jede Interprozesskommunikation implementieren, die Sie benötigen, um einen beliebigen Status zwischen verschiedenen Servern, virtuellen Hosts oder Webapps auf einer beliebigen Anzahl von Tomcats/Webservern/was auch immer zu synchronisieren.

Ein weiterer Grund, warum Sie tomcats Session-Cookie nicht für Ihre eigenen Zwecke verwenden können, ist, dass mehrere Webapps auf demselben Host unterschiedliche Sitzungs-IDs haben. Z.B. Es gibt verschiedene Cookies für "/ webapp1" und "/ webapp2". Wenn Sie das Cookie "/ webapp1" an "/ webapp2" übergeben, würde dies die Sitzung, auf die Sie verwiesen haben, nicht finden, Ihre Sitzung + Cookie ungültig machen und eine eigene neue setzen. Sie müssen die gesamte tomcats-Sitzungsbehandlung neu schreiben, um externe Sitzungs-ID-Werte (schlechte Idee, Sicherheit) zu akzeptieren oder um einen bestimmten Status zwischen Anwendungen zu teilen.

Sitzungsbehandlung sollte als das Geschäft der Behälter (Tomcats) betrachtet werden. Was immer Sie sonst noch brauchen, sollten Sie hinzufügen, ohne das zu stören, was der Container für notwendig hält.

Answer 4

Die Ventiltechniken scheinen nicht zu 100% perfekt zu sein. Wenn Sie es wagen Tomcat zu ändern sich:

catalina.jar enthält die folgende Klasse: org.apache.catalina.connector.Anfrage

Der Antrag hat eine Methode:

configureSessionCookie(Cookie cookie) 

Für unsere Umwelt ist es am besten war es einfach zu codieren, aber man konnte nicht mehr Phantasie Logik:

cookie.setDomain(".xyz.com"); 

scheint perfekt zu arbeiten. Wäre schön, wenn das in Tomcat konfigurierbar wäre.

Answer 5

Ich bin gerade durch all dies auf der Suche nach einer einfachen Lösung gegangen. Ich habe es zuerst aus der Katerperspektive betrachtet.

Tomcat gibt keinen direkten Zugriff auf die Konfiguration des Domain-Cookies für die Sitzung, und ich wollte definitiv nicht benutzerdefinierte Patch Tomcat, um das Problem zu beheben, wie in einigen anderen Posts gezeigt.

Ventile in Tomcat scheint auch eine Problemlösung aufgrund der Einschränkungen beim Zugriff auf Header & Cookies in die Servlet-Spezifikation eingebaut werden. Sie scheitern auch vollständig, wenn die HTTP-Antwort festgelegt wird, bevor sie an Ihr Ventil übergeben wird.

Da wir unsere Anfragen über Apache übertragen, bin ich dann zur Verwendung des Apache gegangen, um das Problem zu beheben.

Ich habe zuerst versucht, die mod_proxy Direktive ProxyPassReverseCookieDomain, aber es funktioniert nicht für JSESSIONID Cookies, weil Tomcat nicht das Domain-Attribut und ProxyPassReverseCookieDomain kann nicht funktionieren, ohne eine Art von Domäne als Teil des Cookies.

Ich bin auch auf einen Hack mit ProxyPassReverseCookiePath gestoßen, wo sie den Pfad neu geschrieben haben, um dem Cookie ein Domänenattribut hinzuzufügen, aber das fühlte sich für eine Produktionsstätte zu unordentlich an.

Ich habe es schließlich funktioniert, indem ich die Response-Header mit dem Modul mod_headers in Apache neu geschrieben habe, wie von Dave oben erwähnt.

Ich habe die folgende Zeile in der virtuellen Host-Definition hinzugefügt:

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" 

Das vor allem eine einzige Zeile in der Config sein sollte. Es ersetzt alle JSESSIONID Cookies Domain-Attribute durch ".example.com". Wenn ein JSESSIONID-Cookie kein Domänenattribut enthält, fügt das Muster ein solches mit dem Wert ".example.com" hinzu. Als Bonus leidet diese Lösung nicht unter dem doppelten JSESSION-Cookies-Problem der Ventile.

Das Muster sollte mit mehreren Cookies im Set-Cookie-Header funktionieren, ohne die anderen Cookies in der Kopfzeile zu beeinflussen. Es sollte auch modifizierbar sein, um mit anderen Cookies zu arbeiten, indem JSESSIONID im ersten Teil des Patterns auf den von Ihnen gewünschten Cookie-Namen geändert wird.

Ich bin nicht reg-ex-Power-User, also bin ich sicher, es gibt ein paar Optimierungen, die an das Muster gemacht werden könnten, aber es scheint für uns so weit zu arbeiten.

Ich werde diesen Beitrag aktualisieren, wenn ich irgendwelche Fehler mit dem Muster finde. Hoffentlich wird das einige von euch davon abhalten, die letzten paar Tage Frustrationen durchzustehen, wie ich es getan habe.