it-swarm.com.de

Chrome-Cookies funktionieren nach dem Neustart des Tomcat-Webservers nicht

Ich habe kürzlich festgestellt, dass der Chrome-Browser beim Neustart meines Tomcat-Webservers keine Cookies mehr speichern kann. Das heißt, Tomcat verwendet Cookies für HTTP-Sitzungen, und der Browser kann seine HTTP-Sitzung nicht mehr abrufen. Auch das Cookie, das wir zum Speichern des angemeldeten Benutzers verwenden, schlägt fehl und der Benutzer bleibt nicht angemeldet.

Dies scheint ein neues Problem mit Chrome zu sein, vielleicht aus einem kürzlich durchgeführten Update. Ich erinnere mich nicht, es zuvor gesehen zu haben. Wenn ich den Chrome-Browser schließe und ihn dann wieder öffne, ist er wieder in Ordnung (bis der Server erneut gestartet wird).

Das Problem tritt bei Firefox nicht auf, scheint in Chrome ein Fehler zu sein.

Hat jemand dieses Problem bemerkt oder von einer Lösung gewusst?

Ich habe einige Beiträge zu Chrome/Tomcat-Cookie-Problemen und dem Vorschlag gefunden, SessionCookiePathUsesTrailingSlash = false in der context.xml Zu setzen, aber das Problem wird dadurch nicht behoben.

Es hat den Anschein, dass es mit der Website zusammenhängt, die sowohl https als auch http unterstützt, und zwischen beiden hin und her wechselt (obwohl sie auf einer Website auftrat, die auch nicht https unterstützte ...).

Okay, ich kann das Problem jetzt wiederherstellen, Schritte sind.

  1. verbindung zur Website über https
  2. abmelden Anmelden
  3. verbindung zur Website über http
  4. Tomcat JSESSIONID-Cookie kann nicht mehr gespeichert werden (seltsame Benutzer-/Passwort-Cookies werden gespeichert)

Dies geschieht nur in Chrome und erst seit dem Chrome-Update, das das Kennzeichen "unsicher" auf Anmeldeseiten hinzufügt, die http verwenden

Okay, ich habe dies zu meiner web.xml hinzugefügt

<session-config>
    <cookie-config>
        <http-only>true</http-only>
        <secure>true</secure>
    </cookie-config>
</session-config>

Dies behebte das Problem nicht, aber das Problem trat immer über http auf, dh http konnte den JSESSIONID-Cookie nicht mehr speichern. Ich habe <secure>false</secure> versucht, aber immer noch das alte Problem. . es hängt zumindest mit dieser Einstellung zusammen. Hat jemand Ideen?

Protokollierter Fehler in Chrome, https://bugs.chromium.org/p/chromium/issues/detail?id=698741

17
James

Ich konnte Ihr Problem mit Chrome reproduzieren: Es ist nur erforderlich, HttpSessionaus der HTTPS-Zone zu erstellen. Bei jeder nachfolgenden HTTP-Anforderung wird das Sitzungscookie nicht gesendet, und alle Versuche, Set-Cookie:JSESSIONID= über HTTP zu senden, werden von Chrome ignoriert. 

Das Problem ist lokalisiert, wenn der Benutzer von HTTPS zu HTTP wechselt. Das HTTPS-Sitzungscookie bleibt auch dann erhalten, wenn der Server neu gestartet wird und ordnungsgemäß funktioniert. (Ich habe mit Tomcat6, Tomcat 9 und einem Apache-Proxy für SSL getestet)

Dies ist der Antwortheader, der von Tomcat gesendet wird, wenn eine Sitzung aus HTTPS erstellt wird

 Set-Cookie: JSESSIONID=CD93A1038E89DFD39F420CE0DD460C72;path=/cookietest;Secure;HttpOnly

und dieses für HTTP (Hinweis Securefehlt)

 Set-Cookie:SESSIONID=F909DBEEA37960ECDEA9829D336FD239;path=/cookietest;HttpOnly

Chrome ignoriert den zweiten set-Cookie. Auf der anderen Seite ersetzen Firefox und Edge das Cookie Securedurch das Zeichen not -securedname__. Um festzustellen, wie das richtige Verhalten sein sollte, habe ich RFC2109 überprüft.

4.3.3 Cookie Management

Wenn ein Benutzeragent einen Set-Cookie-Antwortheader erhält, dessen NAME Derselbe ist wie ein bereits vorhandener Cookie, und dessen Attributwerte für Domäne und Pfad Genau (Zeichenfolge) mit denen eines zuvor Bestehender Keks ersetzt der neue Keks den alten.

Es ist also ein Chrome-Bug, wie Sie in der Frage vermuteten: Der HTTP-Cookie sollte den von HTTPS festgelegten ersetzen

Wenn Sie das Cookie manuell aus Chrome entfernen oder die Sitzung auf dem Server ungültig machen, funktioniert es erneut (wenn nach diesen Aktionen die Sitzung mit HTTP erstellt wird).

Das JSESSIONID-Cookie wird standardmäßig mit Secureerstellt, wenn es von HTTPS angefordert wird. Ich denke, das ist der Grund, warum Chrome den Cookie nicht überschreiben darf. Wenn Sie versuchen, <secure>false</secure> in web.xml zu setzen, ignoriert Tomcat es und der Set-Cookie-Header wird mit Securegesendet.

<session-config>
    <cookie-config>
        <http-only>true</http-only>
        <secure>true</secure>
    </cookie-config>
</session-config>

Das Ändern des Cookie-Namens, das Setzen von sessionCookiePathUsesTrailingSlashoder das Entfernen von HttpOnlyhat keine Auswirkungen

Ich konnte keine Problemumgehung für dieses Problem finden, es sei denn, die Serversitzung wurde ungültig, wenn der protokollierte Benutzer von HTTPS zu HTTP wechselt. 

Schließlich habe ich einen Fehler in Chrom geöffnet: https://bugs.chromium.org/p/chromium/issues/detail?id=698839


AKTUALISIERT Das Problem wird schließlich als nicht behoben gekennzeichnet, da es sich um eine beabsichtigte Änderung handelt. Siehe https://www.chromestatus.com/feature/4506322921848832

Strikte sichere Cookies

Dadurch werden Einschränkungen für Cookies hinzugefügt, die mit dem Attribut "Sicher" gekennzeichnet sind. Derzeit kann auf sichere Cookies nicht von unsicheren (z. B. HTTP) Ursprüngen zugegriffen werden. Unsichere Ursprünge können jedoch immer noch sichere Cookies hinzufügen, löschen oder indirekt entfernen. Diese Funktion ändert den Keksdose, sodass unsichere Ursprünge in keiner Weise sichere Cookies berühren können. Dies lässt eine Auslöschung der Cookies zu, was zu einer Löschung der sicheren Cookies führen kann, jedoch erst, nachdem alle nicht sicheren Cookies entfernt wurden.

8
pedrofb

Ich erinnere mich, dass ich das ein paar Mal gesehen habe und soweit ich mich erinnern kann, war dies die einzige Empfehlung in dieser Angelegenheit, wie Sie gesagt haben:

Eine mögliche Lösung dafür könnte das Hinzufügen von sessionCookiePathUsesTrailingSlash=false in den context.xml sein und sehen, wie das geht.

Einige Infos zur Sache von hier

 enter image description here

Eine Diskussion hier (gleiche Lösung)

Hoffe, ich habe die Probleme nicht verwirrt und das hilft dir, lass mich mit einem Kommentar wissen, ob ich bearbeiten/bearbeiten muss/ob ich lösche, danke!

1
t1f

Es gibt ein Entwurfsdokument , um die Änderung von "sicheren" Cookies aus nicht sicheren Quellen (von Google übermittelt) abzulehnen. Sie gibt die Empfehlungen zur Änderung des Dokuments HTTP State Management Mechanism an. 

Auszug aus dem Dokument:

Dieses Dokument aktualisiert RFC6265, indem die Fähigkeit für nicht
Sichern Sie Origin, um Cookies mit einem "sicheren" Kennzeichen zu setzen und zu überschreiben
Cookies, deren 'sicheres' Flag gesetzt ist. Diese Abwertung verbessert die
Isolation zwischen HTTP- und HTTPS-Ursprung und verringert das Risiko von
böswillige Einmischung.

Chrome diese Funktion wurde bereits in Version 52 implementiert und dieselbe Funktion ist auch in Mozilla implementiert einige Tage zurück. 

Um dieses Problem zu lösen, sollten Sie sich nur über https mit der Website verbinden.

0
skadya

Ich denke, der schlechte Weg ist, sessionCookieName = "JSESSIONIDForHttp" in context.xml einzustellen.

Lassen Sie den Cookie des Browsers wissen:

  1. Wenn die https-Bedingung sicher ist, verwenden Sie die Standardeinstellung "JSESSIONID".

  2. Wenn die http-Bedingung nicht sicher ist, verwenden Sie "JSESSIONIDForHttp".

0
巧克力