jboss cluster session replikation funktioniert nicht (mehrere jsessionid cookies)

Question

Ich versuche, mich auf meiner Webanwendung zu authentifizieren, die auf einem jboss im Cluster-Modus mit 2 Knoten ausgeführt wird.

Nach einer erfolgreichen Authentifizierung ich auf eine Admin-Seite weitergeleitet, wo einen Filter überprüft, ob ich angemeldet bin.

Auf Standalone-Modus es funktioniert gut, aber wenn ich in der Produktion eingesetzt, die Cluster-Modus verwendet, wobei die Filter lehnt meine Anfrage ab, weil sie nicht auf die Sitzungsparameter zugreifen kann, die ich bei der Authentifizierung eingerichtet habe.

Mit den Entwicklertools ich dort zu sehen sind 3 JSESSIONID Cookies: eine für /, eine für /myapplication Pfad und eine andere namens JSESSIONID-34234 auch für /myapplication Pfad (Ich habe alle clearen vor dem Start des Prozesses).

Beim Durchsuchen der JBoss-Dokumente kann ich keine Erklärung dafür finden, obwohl es die Quelle meines Problems scheint.

Wie kann ich zur Arbeit Authentifizierung (ich benutze Spring-Sicherheit http Form basierte Authentifizierung) in meinem JBoss-Cluster?

Answer 1

durch Aktivierung klebrig Sitzung Gelöst Folgendes Virtualhost-Konfigurationsdatei durch Hinzufügen:

Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/myapplication" env=BALANCER_ROUTE_CHANGED 
<Proxy balancer://jboss6-hc-001-8109> 
    BalancerMember ajp://jboss2.imatiasl.lan:8109 route=jboss2-hc-001-server-02 
    BalancerMember ajp://jboss3.imatiasl.lan:8109 route=jboss3-hc-001-server-02 
    ProxySet lbmethod=byrequests stickysession=ROUTEID 
</Proxy> 

Answer 2

Web Session-Clustering sollten, wenn Arbeit:

1. Sie <distributed/> in web.xml aktiviert.
2. App-Server-Gruppe wird mit ha oder full-ha Profil

Wenn Sie Ihre Cluster-App besser ausführen möchten, sollten Sie eine gute Lastausgleichspolitik. Für die meisten Webapps ist Load-Balancing mit Sticky-Sessions in Ordnung.

In einigen Webapps reicht es nicht, im Falle eines Failovers nach einer erneuten Authentifizierung zu fragen, oder die Sitzung kann sehr einfach neu erstellt werden, wenn Authentifizierungsinformationen verfügbar sind. In solchen Fällen benötigen Sie kein Web-Session-Clustering. Clustered SSO ist genug, der Vorbehalt ist, dass Sie Container-Level-Sicherheit für die Authentifizierung verwenden müssen (höchstwahrscheinlich von Feder-Sicherheit unterstützt). Auf diese Weise werden nur Authentifizierungsinformationen repliziert. Daher müssen Sie das Sitzungsdatenmanagement so gestalten, dass es Situationen standhält, in denen die Sitzung plötzlich leer wird.