Deichgraf17 0 Geschrieben 5. Februar 2014 Autor Melden Teilen Geschrieben 5. Februar 2014 hm... Nach ein paar Tests stellt sich heraus, dass dieses Problem Xwiki spezifisch ist. Die anderen Applikationen behalten ihre Sessions. Heute Nachmittag werde ich mich da verstärkt reinknien und der Sache auf den Grund gehen. Die Session ID ist definitiv nich tim Query-String bei Xwiki Zitieren Link zu diesem Kommentar
Daniel -MSFT- 129 Geschrieben 5. Februar 2014 Melden Teilen Geschrieben 5. Februar 2014 (bearbeitet) Hi Deichgraf17, bei XWiki steht in der FAQ, dass das Session-Handling nicht von XWiki, sondern von dem darunterliegenden Java Servlet-Runner (bei Dir Tomcat) betrieben wird: http://www.xwiki.org/xwiki/bin/view/FAQ/How+can+I+change+the+Session+timeout. Viele Grüße, Daniel bearbeitet 5. Februar 2014 von Daniel -MSFT- Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 5. Februar 2014 Melden Teilen Geschrieben 5. Februar 2014 ...also vermutlich eine "normale" JSESSIONID. @Daniel, Dein Link geht leider nicht.. Zitieren Link zu diesem Kommentar
Deichgraf17 0 Geschrieben 5. Februar 2014 Autor Melden Teilen Geschrieben 5. Februar 2014 hm... Am Session Timeout von Tomcat liegt es definitiv nicht. Das ist auf 30 Minuten eingestellt. Wenn ich mit Wireshark versuche nachzuvollziehen was passiert kann ich folgendes feststellen: Verbinde ich mich mit Nexus und logge ein, kann ich deutlich den Handshake nachvollziehen. Dieser kommt von einer Source IP und geht an eine Destination IP (beide nicht die, die ich hier vergeben habe). Im Trace mit Xwiki kann ich den Handshake nirgends finden. Source und Destination sind keine IP Adressen sondern wilde folgen von Zeichen und eine Menge Broadcasts dazwischen. Nr Time Source Destination Protocol 2748 72.921283000 Avm_95:f0:e1 AtherosC_00:00:01 HomePlug AV 60 MAC Management, Central Coordination Discovery List Request <<< eine Zeile aus dem Trace für Xwiki Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 5. Februar 2014 Melden Teilen Geschrieben 5. Februar 2014 Gibt mal JSESSIONID bei Google ein und benutze dann wieder Fiddler... Zitieren Link zu diesem Kommentar
Daniel -MSFT- 129 Geschrieben 5. Februar 2014 Melden Teilen Geschrieben 5. Februar 2014 (bearbeitet) Nr Time Source Destination Protocol 2748 72.921283000 Avm_95:f0:e1 AtherosC_00:00:01 HomePlug AV 60 MAC Management, Central Coordination Discovery List Request <<< eine Zeile aus dem Trace für Xwiki Das kommt von einem PowerLAn-Adapter von AVM und hat mit Deinem Problem vermutlich nichts zu tun. Was das Sessionhandling angeht, ja, der Default-Timeout ist 30 Sekunden bei Tomcat. Daran liegt es auch nicht. Sondern vermutlich am Inhalt der Session ID wegen des Reverse Proxies. Lies mal hier weiter: https://stackoverflow.com/questions/9486498/how-to-properly-set-jsessionid-cookie-path-behind-reverse-proxy und https://mail-archives.apache.org/mod_mbox/httpd-users/201301.mbox/%3CCAAKASGy_Zr46OA34SNqejGevEjxt-NeauuRyU2KKDJ3P__PnUw@mail.gmail.com%3E. An der Stelle erlaube ich mir mal die Nachfrage, warum Du das eigentlich so machst und was Du genau damit erreichen willst. Vielleicht gibt es ja auch einen viel einfacheren Weg für Dein Vorhaben. Have fun! Daniel bearbeitet 5. Februar 2014 von Daniel -MSFT- Zitieren Link zu diesem Kommentar
Deichgraf17 0 Geschrieben 7. Februar 2014 Autor Melden Teilen Geschrieben 7. Februar 2014 (bearbeitet) hm... Waren Vorgaben vom Chef. Das Problem lag am Cookie von Xwiki. useip=false war hier die Lösung. Damit lief unser System dann auch genau so, wie wir es haben wollten. Habe die Ports dann noch dicht gemacht und wollte alles schön dokumentieren. Leider hat sich dann unser .NET framework zerschossen und nix ging mehr. Dann hat Chef uns das Projekt entzogen :( 20 Arbeitstage seien zu viel für nur einen Desktop PC. bearbeitet 7. Februar 2014 von Deichgraf17 Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.