# Warum zwei Sessioncookies?



## BlackCraze (14. Jan 2008)

Hallo,

Wir haben hier eine Intranetanwendung auf einem JBoss 4.0.4 mit einem Tomcat 5.5.
Die nutzt als Grafikframework Echo2 und hat sonst keine modifikationen am Sessionhandling.

Wenn die Applikation aufgerufen wird, werden seltsamerweise gleich zwei Sessioncookies angelegt. Beide haben den gleichen Host und den gleichen Inhalt (sessionID). Nur der Sessioncontext ist unterschiedlich - der eine coockie hat den Pfad der Anwendung auf dem Server, das andere den Rootcontext. 

Verdeutlichung:

http://server.im.lokalnetz:8080/dieanwendung

erzeugt zwei cookies:

Coockie1
Name: JSESSIONID
Host: server.im.lokalnetz
Pfad: /dieanwendung
Content: SESSIONID

Coockie2
Name: JSESSIONID
Host: server.im.lokalnetz
Pfad: /
Content: SESSIONID


Der zweite Cookie zerstört mir die Sessions der anderen Webapplikationen auf der gleichen JBoss-Instanz.
Wie kann sowas passieren? (also dass da zwei angelegt werden)
Ich weiß gar nicht, wo ich anfangen soll zu suchen. Von sowas hab ich noch nie gehört?!?!!

Danke schonmal für Anregungen ^^


----------



## maki (14. Jan 2008)

Hast du vielleciht die Anwendung 2mal am laufen, einmal als ROOT Context und einmal mit "richtigem" Context?

Einfach zu testen, einmal im Browser mit richtigem Context aufrufen, dann mit ROOT (also ohne) context .


----------



## BlackCraze (14. Jan 2008)

Nein. Die Anwendung ist nur einmal im Deployverzeichnis vom JBoss. Der Browseraufruf des rootcontextes bringt mich zum JBoss-Startbildschirm.

Auch interessant:
lösche ich den coockie mit dem leeren context, wird dieser nicht wieder angelegt. Solange, bis ich die Session schließe (beide cookies verschwinden) und wieder neu aufrufe.


----------



## maki (14. Jan 2008)

> Nein. Die Anwendung ist nur einmal im Deployverzeichnis vom JBoss.


Das heisst gar nix, man kann einem Deployverzeichniss beliebig viele Kontexte zuweisen und jeder Context wird als eigene Anwendung behandelt(!).

Geh doch mal direkt auf den Tomcat nicht über JBoss (anderer Port).

Nachtrag: Sind alle deine Referenzen mit dem Context? Wenn nicht, wird der root context verwendet, daher könnte das Cookie kommen. Ruf doch mal ein paar Bilder oder ähnliches direkt über die URL auf.


----------



## BlackCraze (14. Jan 2008)

Ich weiß nicht so recht, wie ich den Tomcat selbst ansteuern soll.
Der JBoss hat nur eine Instanz. Diese macht ja praktisch eine Portweiterleitung an den Tomcat, wenn ich mich recht erinnere. Die Ports werden in der jboss-bindings.xml vom JBoss und der server.xml vom tomcat konfiguriert. Kann ich den Tomcat überhaupt direkt ansprechen? Welcher Port ist das in der Configdatei? Ist schon etwas her, dass ich das mal eingestellt habe. Die Anwendung ist übrigens ein ear-Archiv. Schon allein darum kann ichs nicht direkt am Tomcat testen, oder?

Alle Anwendungen funktionieren getrennt voneinander wunderbar und legen auch ihre normalen Sessioncookies an (mit richtigem Pfad). Nur diese eine Anwendung erzeugt beim ERSTEN starten zusätzlich dieses cookie mit dem Pfad auf "/" gesetzt. Daraufhin funktioniert nur noch die besagte fehlerhafte Anwendung, da der Cookie mit dem "/"-Pfad scheinbar irgendwie vom Browser bevorzugt wird. Da in diesem Cookie die SessionID der Anwendung drin steht, funktioniert die auch problemlos weiter. Lösche ich diesen Cookie manuell, funktionieren alle Anwendungen wieder. 

Beim weiteren Navigieren durch die fehlerhafte Anwendung wird der cookie nicht neu angelegt. 
Lösche ich den "/"-Cookie taucht er nicht wieder auf.

Lösche ich hingegen den "/meineanwendung"-Cookie, wird dieser beim weiternavigieren wieder angelegt. Die Session geht auch hier nicht verloren, da ja der "/"-Cookie die richtige SessionID hat ^^

Ich hoffe, ich erzeuge keine Verwirrung. :-D



> Nachtrag: Sind alle deine Referenzen mit dem Context? Wenn nicht, wird der root context verwendet, daher könnte das Cookie kommen. Ruf doch mal ein paar Bilder oder ähnliches direkt über die URL auf.


Welche Refernzen? Welcher Context? Ich dreh gleich durch :-D
Wie meinst du das mit dem Bild aufrufen? Dabei wird doch kein Cookie angelegt?


----------



## maki (14. Jan 2008)

> Ich weiß nicht so recht, wie ich den Tomcat selbst ansteuern soll.
> Der JBoss hat nur eine Instanz. Diese macht ja praktisch eine Portweiterleitung an den Tomcat, wenn ich mich recht erinnere. Die Ports werden in der jboss-bindings.xml vom JBoss und der server.xml vom tomcat konfiguriert. Kann ich den Tomcat überhaupt direkt ansprechen? Welcher Port ist das in der Configdatei?


Weiss nicht genau was du meinst, allerdings steht in der server.xml an welchem Port TC lauscht, und in der Log datei auch.



> Die Anwendung ist übrigens ein ear-Archiv. Schon allein darum kann ichs nicht direkt am Tomcat testen, oder?


Kann ich von hier aus nicht genau sagen, allerdings sollte es möglich sein das *.war Archiv zu extrahieren und auf einem anderen (zumindest) lokalen Tomcat zu testen, während der Rest der Anwendung im JBoss (auch lokal) weiterläuft.



> Welche Refernzen? Welcher Context? Ich dreh gleich durch icon_biggrin.gif
> Wie meinst du das mit dem Bild aufrufen? Dabei wird doch kein Cookie angelegt?


"dieanwendung" wäre der Context deiner Anwendung

Eine jsessionId wird angelegt wenn ein Client auf den Server zugreift und noch keine Session zugeordnet hat. Wann die Session Id in ein Cookie geschrieben wird ist eine andere Sache...

Ich vermute das irgendwo in einer JSP/HTML Seite (oder gar einem Servlet)  eine URL (das meinte ich mit Referenz) den Context nicht berücksichtig (kein getContext() oder absolute URL).
Entweder das oder es wird explizit gesetzt.


----------



## BlackCraze (14. Jan 2008)

Okay - ich werde das morgen früh mal testen.
Danke für die Anregung - klingt zumindest erstmal nach einer vernünftigen Spur


----------



## BlackCraze (9. Feb 2008)

Ist zwar jetzt schon etwas her - aber das Problem wurde durch zwei Filter und eine Weiterleitung ausgelöst. Zusammen mit dem Umstand, dass der Pfad eines Cookies aufgrund fehlerhafter Browserimplementierungen nicht immer ausgelesen werden kann (steht so in der API).

trotzdem nochmal vielen Dank


----------

