Senden von Browser-Cookies während einer 302-Weiterleitung

84

Gibt es Probleme beim Zurücksenden eines Cookies während einer 302-Umleitung? Wenn ich beispielsweise ein Cookie für die Rückkehr zur URL erstelle und den Benutzer in derselben Antwort umleitung, ignoriert dann ein (moderner) Browser das Cookie?

http cookies http-status-code-302

— Abdullah Jibaly
quelle

Wenn ich ein bisschen lese, denke ich, dass Sitzungsvariablen besser sind als Cookies, da sie serverseitig sind und nicht von der Vorhersagbarkeit des Clients abhängen.

— ADTC

38

Die meisten Browser akzeptieren Cookies für 302 Weiterleitungen. Da war ich mir ziemlich sicher, aber ich machte eine kleine Suche. Nicht alle modernen Browser. Internetarchiv Link von einer jetzt entfernten / toten / Microsoft-Verbindung Q / A auf dem Silverlight Client HTTP-Stack ignoriert Set-Cookie bei 302 Redirect Responses (2010)

Ich denke, wir haben jetzt einen Ersatz für IE6 und es sind Windows Mobile-Browser ...

— Regilero
quelle

1

Auf die von Ihnen angegebene Forenseite kann mit der URL nicht zugegriffen werden. Meinen Sie damit, dass IE6- und Windows Mobile-Browser dies nicht sind?

— Hiroshi

1

Link wurde verschoben. Ich habe einen neuen Link mit ziemlich demselben Inhalt gesetzt. und ich meinte, IE-spezifische Versionen für Mobilgeräte fügen ihre eigenen Fehler hinzu

— regilero

50

Laut diesem Blog-Beitrag: http://blog.dubbelboer.com/2012/11/25/302-cookie.html alle gängigen Browser, IE (6, 7, 8, 9, 10), FF (17), Safari (6.0.2), Opera (12.11) unter Windows und Mac setzen Cookies für Weiterleitungen. Dies gilt sowohl für 301- als auch für 302-Weiterleitungen.

— Gavenkoa
quelle

Leider enthält diese Liste nicht Chrome, so dass wir nicht genau alle

— gängigen

3

@MestreLion: In meinem Chrome-Browser funktioniert es. Also ... ich denke, wir können sagen, dass es jetzt endlich funktioniert, im Jahr 2019.

— Michael

38

Ein Hinweis (um Entwicklern das Leben zu retten):

IE und Edge ignorieren Set-Cookie in der Umleitungsantwort, wenn die Domäne des Cookies localhost ist .

Lösung:

Verwenden Sie 127.0.0.1 anstelle von localhost .

— Michal Maťovčík
quelle

11

IE und Edge haben dies möglicherweise "behoben", sodass sie auch keine Cookies für 127.0.0.1 setzen. Doh! Und sie fragen sich, warum Entwickler nicht alle IE lieben ... Ihre Antwort endete immer noch mit ungefähr 4 Stunden Kopfkratzen für mich. Vielen Dank!

— GlenPeterson

18

Hier ist der Chromium-Fehler für dieses Problem (Set-Cookie für HTTP-Antwort mit Status 302 ignoriert).

— llambda
quelle

1

Wenn dies wahr ist, ist es in der Tat eine wirklich schlechte Nachricht :-(

— MestreLion

Ich denke, sie haben es behoben. Der Fehlerbericht sagt immer noch "WontFix", aber in meinem Chrome-Browser funktioniert es.

— Michael

@ Michael beachten Sie, dass Chromium nicht Chrome ist: lifewire.com/chromium-and-chrome-differences-4172101 - das bedeutet, dass es zwar in Chrome funktioniert, aber nicht unbedingt für Chromium gilt

— Thomas

3

Dies ist ein wirklich verpönter Ansatz, aber wenn Sie sich wirklich nicht auf das 30-fache Verhalten des Set-Cookie-Browsers verlassen möchten, können Sie meta http-equiv="refresh"beim Setzen des Cookies eine HTML- Umleitung verwenden. Zum Beispiel in PHP:

<?php
    ...
    setcookie("cookie", "value", ...);
    url="page.php";
?>
<html>
<head><meta http-equiv="refresh" content=1;url="<?=$url?>"></head>
<body><a href="<?=$url?>">Continue...</a></body>
</html>

Der Server sendet ein Set-Cookie mit einer 200 anstelle einer richtigen 300-fachen Umleitung, sodass der Browser das Cookie speichert und dann die "Umleitung" durchführt. Der <a>Link ist ein Fallback für den Fall, dass der Browser die Metaaktualisierung nicht durchführt.

— MestreLion
quelle

0

Ich bin gerade auf dieses Problem mit Firefox und Safari gestoßen, aber nicht mit Chrome. Nach meinen Tests geschieht dies nur, wenn sich die Domäne während der Umleitung ändert. Dies ist typisch für einen OAuth2-Fluss:

Der OAuth2-ID-Anbieter (GitHub, Twitter, Google) leitet den Browser zurück zu Ihrer App
Die Rückruf-URL Ihrer App überprüft die Autorisierung, setzt Anmelde-Cookies und leitet dann erneut zur Ziel-URL weiter
Ihre Ziel-URL wird ohne gesetzte Cookies geladen.

Aus Gründen, die ich noch nicht herausgefunden habe, werden einige Cookies aus Anfrage 2 ignoriert, andere nicht. Wenn jedoch Anforderung 2 ein HTTP 200 mit einem RefreshHeader zurückgibt (die "Meta Refresh" -Umleitung), werden Cookies durch Anforderung 3 ordnungsgemäß gesetzt.

— Kiran Jonnalagadda
quelle

0

Dieses Problem ist bei der Verwendung von OpenIdConnect in .Net aufgetreten, wo eine separate API die Authentifizierung übernimmt und zur Hauptwebsite zurückleitet.

Zunächst müssen Sie die CookieSecureOption festlegen SameAsRequestoder Neverdamit umgehen, dass Sie http://localhost/nicht sicher sind. Siehe Michael Freidgeims Antwort.

Zweitens muss auch das CookieSameSiteAttribut auf gesetzt werden Lax, sonst werden die Cookies nicht gespeichert.

— Willem
quelle

-1

In meinem Fall habe ich CookieOptions.Secure = true gesetzt, es aber auf http: // localhost . Getestet und Cookies entsprechend der Einstellung im Browser ausgeblendet .

Um ein solches Problem zu vermeiden, können Sie die Option Cookie Secure so einstellen, dass sie mit dem Protokoll Request.IsHttps übereinstimmt, z

new CookieOptions()
                {
                    Path = "/",
                    HttpOnly = true,
                    Secure = Request.IsHttps,
                    Expires = expires
                }

— Michael Freidgeim
quelle

2

Setzen Sie in diesem Fall nicht das sichere Flag . Der Sinn des Flags besteht darin, den Browser anzuweisen, das Cookie nur beim Herstellen einer Verbindung über HTTPS zu verwenden. Das bedingte Setzen des Flags ändert die Semantik etwas, und Sie verlieren das Cookie beim Übergang von HTTPS -> HTTP, jedoch nicht, wenn Sie von HTTP -> HTTPS wechseln. All dies ist orthogonal zu dem, was Browser mit Set-CookieHeadern bei 302-Weiterleitungen tun .

— Martijn Pieters

1

Dieses Mal, wenn die Antwort mit -3 Stimmen das Problem löst. Ich habe Secure = true gesetzt, aber vergessen, dass ich auf localhost nur http verwende, um es zu testen. Noob Fehler. Verwendet secure=request.is_securein Kolben.

— Eloff