Session-Cookies und IE 8

Ich vor kurzem eine einfache web-app bereitgestellt, über Tomcat. Nutzt die app ziemlich standard-session-basierte Sicherheit, wo ein Benutzer angemeldet hat, erhält eine session.

Sitzungen funktionieren in Firefox und Chrome auf, jedoch erfordern die Verwendung von jsessionid in der URL für den IE (getestet 7 & 8), "Mittel" betreffen. Im IE 8, ich habe versucht, override cookie handling, Einstellung "Erlaube alle 3rd-party-cookies" und "alle Zulassen" session-cookies"- keine Würfel. Allerdings wenn ich Tomcat auf meinem lokalen Rechner, IE akzeptiert die Cookies, und sessions arbeiten einwandfrei.

Und jetzt für die HTTP-Header.

Aus Chrom, ein Benutzer eingeloggt ist, bekommt eine Sitzung

GET http://devl:8080/testing/HTTP/1.1
Host: devl:8080
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.1.249.1036 Safari/532.5
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
P3P: CP="NON CURa ADMa DEVa TAIa OUR BUS IND UNI COM NAV INT STA"
Set-Cookie: JSESSIONID=9280023BCE2046F32B13C89130CBC397; Path=/testing
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Content-Length: 2450
Date: Fri, 26 Mar 2010 14:14:40 GMT

GET http://devl:8080/testing/logout HTTP/1.1
Host: devl:8080
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.1.249.1036 Safari/532.5
Referer: http://devl:8080/testing/
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: JSESSIONID=9280023BCE2046F32B13C89130CBC397

...

Vom IE 8, mit standard-medium-level-Sicherheit und Datenschutz-

GET http://devl:8080/testing/HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MDDC; Tablet PC 2.0)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Host: devl:8080
Connection: Keep-Alive

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
P3P: CP="NON CURa ADMa DEVa TAIa OUR BUS IND UNI COM NAV INT STA"
Set-Cookie: JSESSIONID=192999F922D6E9C868314452726764BA; Path=/testing
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Content-Length: 2450
Date: Fri, 26 Mar 2010 14:32:34 GMT

GET http://devl:8080/testing/logout HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Referer: http://devl:8080/testing/;jsessionid=6371A83EFE39A46997544F9146AA5CEA
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MDDC; Tablet PC 2.0)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: devl:8080

...

Ich dachte, es könnte sein, P3P, aber auf eine kompakte Richtlinie das hinzufügen, ändert sich nichts. Dies ist der standard-Tomcat-session, so dass ich bin wirklich überrascht, dass ich nicht in der Lage gewesen zu finden, anderen Menschen mit dem gleichen problem so weit. Jemand irgendwelche Ideen?

BEARBEITEN 4/3/2010 -

Sorry wenn ich nicht klar machen - ich habe versucht aus mehreren anderen Instanzen des IE - co-Arbeiter auf dem Flur, etc.

BEARBEITEN 4/3/2010 -

Ich habe auch versucht einschalten der Aufforderung für alle cookies, aber ich nicht bekommen, eine Eingabeaufforderung. Einstellung der Domäne, in der "Set-Cookie" - header mit Fiddler nicht einen Unterschied machen, entweder.

  • Könnte das cookie benötigen die domain gesetzt? Ich weiß nicht, einen Weg zu konfigurieren, die in Tomcat, aber vielleicht konnte ich dich mit den cookie-header mit einem filter...
  • Warum wird der referer in Ihrem letzten IE8 GET gehören die jsessionid in der url? Und welches tool verwenden Sie zur Erfassung der oben genannten Verkehr (cuz ein browser würde nie senden GET http://...)?
  • Eine andere Sache, bemerkte ich aus dem IE8 HTTP-trace: bei der ersten Anfrage versucht, eine session-id "" Set-Cookie: JSESSIONID=192999F922D6E9C868314452726764BA; Path=/testing ", aber die zweite Anforderung hat eine andere session-id in der "Referer: ...;jsessionid=6371A83EFE39A46997544F9146AA5CEA". Gab es dazwischen Aktionen zwischen den 2 Anfragen? Gibt es irgendwelche zusätzliche Informationen auf, warum es sein könnte, zwei session-ids? Keine chance, es gibt mehrere windows invovled?
  • Ich vermute, es ist wie Tomcat Griffe-sessions, wenn cookies deaktiviert sind; ich Tue nichts wonky ich glaube nicht, dass... - die einzige Zeit, die ich erstellen Sie eine neue Sitzung, wenn der client nicht über eine.
  • Tomcat fällt zurück auf " akzeptieren ";JSESSIONID=..." angehängt, um die URL zu verbreiten, session-Daten, wenn cookies deaktiviert sind. Ist das nicht etwas komisch IE-Macke (obwohl, es würde nicht passieren, wenn der IE akzeptiert meine cookies)- wenn ein session-cookie ist nicht im Lieferumfang enthalten, die JSP-Seiten enthalten die id in den nachfolgenden URLs.
  • Gibt es irgendwelche Erweiterungen geladen im IE? Pflege, um zu versuchen, es mit Erweiterungen deaktiviert? Jede chance, zu versuchen, von IE auf einen anderen computer (z.B. PC eines Freundes)?
  • Wir hatten ein ähnliches problem, aber es war nicht spezifisch für den IE (und ich kam auf diese Frage in der Suche nach einer Lösung). Es stellte sich heraus, schmerzhaft einfach: ein slash am Ende der URL. Wir waren zum Beispiel Zugriff auf http://.../app die scheitern würden, aber http://.../app/ gearbeitet (auch wenn dies nicht erkennbar war, zu der Zeit). Der Unterschied war, dass die Set-Cookie header zeigte der Pfad war /app/ was bedeutete, dass der Zugriff auf /app bewirkt, dass der cookie nicht gesendet werden, durch den browser (zu Recht). Dies kann nicht Ihr problem zu sein und es scheint, dass Ihre cookie-Pfad /testen, sollte aber funktionieren mit /testing/.

InformationsquelleAutor Matt Luongo | 2010-03-26
Schreibe einen Kommentar