it-swarm.com.de

Cookies auf localhost mit expliziter Domain

Ich muss einige grundlegende Dinge über Cookies vermissen. Wenn Sie auf localhost auf der Serverseite ein Cookie setzen, geben und die Domäne explizit als localhost (oder .localhost) an. Der Cookie scheint von einigen Browsern nicht akzeptiert zu werden.

Firefox 3.5: Ich habe die HTTP-Anfrage in Firebug überprüft. Was ich sehe, ist:

Set-Cookie:
    name=value;
    domain=localhost;
    expires=Thu, 16-Jul-2009 21:25:05 GMT;
    path=/

oder (wenn ich die Domain auf .localhost gesetzt habe):

Set-Cookie:
    name=value;
    domain=.localhost;
    expires=Thu, 16-Jul-2009 21:25:05 GMT;
    path=/

In beiden Fällen wird der Cookie nicht gespeichert.

IE8: Ich habe kein zusätzliches Tool verwendet, aber der Cookie scheint auch nicht gespeichert zu werden, da er in nachfolgenden Anforderungen nicht zurückgesendet wird.

Opera 9.64: Sowohl localhost als auch .localhost work, aber wenn ich die Liste der Cookies in den Einstellungen prüfe, wird die Domäne auf localhost.local gesetzt, obwohl sie unter localhost (in der Listengruppierung) aufgeführt ist.

Safari 4: Sowohl localhost als auch .localhost work, aber sie werden in den Einstellungen immer als .localhost aufgeführt. Auf der anderen Seite ein Cookie ohne explizite Domäne, das nur als localhost (kein Punkt) angezeigt wird.

Was ist das Problem mit localhost? Aufgrund einer solchen Anzahl von Inkonsistenzen müssen spezielle Regeln für localhost gelten. Mir ist auch nicht ganz klar, warum Domänen ein Punkt vorangestellt werden muss. In RFC 2109 heißt es ausdrücklich: 

Der Wert für das Domain-Attribut enthält keine eingebetteten Punkte oder nicht Beginne mit einem Punkt.

Warum? Das Dokument weist darauf hin, dass es etwas mit Sicherheit zu tun hat. Ich muss zugeben, dass ich nicht die gesamte Spezifikation gelesen habe (macht es vielleicht später), aber es klingt ein bisschen seltsam. Auf dieser Basis wäre das Setzen von Cookies auf localhost nicht möglich.

156
Jan Zich

Domänennamen müssen mindestens zwei Punkte haben. Andernfalls werden sie vom Browser als ungültig betrachtet. (Siehe Referenz auf http://curl.haxx.se/rfc/cookie_spec.html )

Bei der Arbeit mit localhost muss die Cookie-Domain vollständig weggelassen werden. Die Einstellung auf "" oder NULL oder FALSE anstelle von "localhost" reicht nicht aus.

Für PHP siehe Kommentare zu http://php.net/manual/de/function.setcookie.php#73107 .

Wenn Sie mit der Java Servlet-API arbeiten, rufen Sie die cookie.setDomain("...")-Methode keinesfalls auf.

201

Ich stimme mit @Ralph Buchfelder im Großen und Ganzen überein, aber hier einige Verbesserungen, experimentieren Sie beim Versuch, ein System mit mehreren Unterdomänen (z. B. beispiel.com, fr.example.com, de.example.com) auf meinem lokalen Computer ( OS X/Apache/Chrome | Firefox).

Ich habe/etc/hosts bearbeitet, um einige imaginäre Subdomains auf 127.0.0.1 zu verweisen:

127.0.0.1 localexample.com
127.0.0.1 fr.localexample.com
127.0.0.1 de.localexample.com

Wenn ich an fr.localexample.com arbeite und den Domain-Parameter auslasse, wird der Cookie für fr.localexample.com korrekt gespeichert, ist jedoch in den anderen Subdomains nicht sichtbar.

Wenn ich eine Domäne von ".localexample.com" verwende, wird der Cookie für fr.localexample.com ordnungsgemäß gespeichert und ist in anderen Subdomains sichtbar.

Wenn ich eine Domain von "localexample.com" verwende oder wenn ich eine Domain mit "localexample" oder "localhost" ausprobierte, wurde der Cookie nicht gespeichert.

Wenn ich eine Domäne von "fr.localexample.com" oder ".fr.localexample.com" verwende, wird der Cookie für fr.localexample.com korrekt gespeichert und ist (richtig) in anderen Subdomains nicht sichtbar.

Die Anforderung, dass Sie mindestens zwei Punkte in der Domäne benötigen, scheint also korrekt zu sein, auch wenn ich nicht sehen kann, warum es so sein sollte.

Wenn jemand das ausprobieren möchte, hier ein nützlicher Code:

<html>
<head>
<title>
Testing cookies
</title>
</head>
<body>
<?php
header('HTTP/1.0 200');
$domain = 'fr.localexample.com';    // Change this to the domain you want to test.
if (!empty($_GET['v'])) {
    $val = $_GET['v'];
    print "Setting cookie to $val<br/>";
    setcookie("mycookie", $val, time() + 48 * 3600, '/', $domain);
}
print "<pre>";
print "Cookie:<br/>";
var_dump($_COOKIE);
print "Server:<br/>";
var_dump($_SERVER);
print "</pre>";
?>
</body>
</html>
28
xgretsch

localhost: Sie können verwenden: domain: ".app.localhost" und es wird funktionieren. Der Parameter 'domain' benötigt einen oder mehrere Punkte im Domainnamen, um Cookies zu setzen. Anschließend können Sie Sitzungen für lokale Subdomains wie: api.app.localhost:3000 ausführen.

23
AmpT

Wenn ein Cookie mit der expliziten Domäne "localhost" wie folgt festgelegt wird ...

Set-Cookie: Name = Wert; domain = localhost; verfällt = Do, 16-Jul-2009 21:25:05 GMT; Pfad = /

... dann ignorieren Browser es, weil es nicht mindestens zwei Perioden enthält und keine von sieben speziell behandelten, Top-Level-Domänen ist. 

... Domänen müssen mindestens zwei (2) oder drei (3) Perioden enthalten, um Verhindern Sie Domänen des Formulars: ".com", ".edu" und "va.us". Beliebige Domain Dies schlägt in einer der sieben aufgeführten speziellen Top-Level-Domänen fehl unten benötigen nur zwei Perioden. Jede andere Domäne erfordert mindestens drei. Die sieben speziellen Top-Level-Domänen sind: "COM", "EDU", "NET", "ORG", "GOV", "MIL" und "INT".

Beachten Sie, dass die Anzahl der oben genannten Zeiträume wahrscheinlich davon ausgeht, dass eine führende Zeitspanne erforderlich ist. Diese Periode wird jedoch in modernen Browsern ignoriert und sollte wahrscheinlich lesen ...

mindestens eine (1) oder zwei (2) Perioden

Beachten Sie, dass der Standardwert für das Domänenattribut der Hostname des Servers ist, der die Cookie-Antwort generiert hat .

Eine Problemumgehung für Cookies, die nicht für localhost festgelegt sind, besteht darin, einfach kein Domänenattribut anzugeben und den Browser den Standardwert verwenden zu lassen. Dies scheint nicht die gleichen Einschränkungen zu haben wie ein expliziter Wert im Domänenattribut.

10
Scott Munro

Ergebnisse, die ich je nach Browser geändert hatte. 

Chrome-127.0.0.1 funktionierte, aber localhost .localhost und "" funktionierten nicht . Firefox- .localhost funktionierte, aber localhost, 127.0.0.1 und "" nicht.

Habe nicht in Opera, IE oder Safari getestet

3
user631063

Ich habe viel Zeit damit verbracht, dieses Problem selbst zu beheben.

Mit PHP und nichts auf dieser Seite funktionierte für mich. In meinem Code wurde mir schließlich klar, dass der 'sichere' Parameter für PHP session_set_cookie_params () immer auf TRUE gesetzt wurde. 

Da ich localhost nicht mit https besuchte, akzeptierte mein Browser den Cookie niemals. Also habe ich diesen Teil meines Codes so geändert, dass der 'sichere' Parameter auf der Grundlage von $ _SERVER ['HTTP_Host'] 'localhost' ist oder nicht. Funktioniert jetzt gut.

Ich hoffe das hilft jemandem.

2
James Jacobson

Keine der vorgeschlagenen Korrekturen funktionierte für mich - es wurde auf null, falsch gesetzt, zwei Punkte hinzugefügt usw. - funktionierte nicht. 

Am Ende habe ich gerade die Domain aus dem Cookie entfernt, wenn es localhost ist und das jetzt für mich in Chrome 38 funktioniert.

Vorheriger Code (funktionierte nicht):

document.cookie = encodeURI(key) + '=' + encodeURI(value) + ';domain=.' + document.domain + ';path=/;';

Neuer Code (funktioniert jetzt):

 if(document.domain === 'localhost') {
        document.cookie = encodeURI(key) + '=' + encodeURI(value) + ';path=/;' ;
    } else {
        document.cookie = encodeURI(key) + '=' + encodeURI(value) + ';domain=.' + document.domain + ';path=/;';
    }
1
DJ_Polly

sie können localhost.org oder besser .localhost.org verwenden, es wird immer in 127.0.0.1 aufgelöst.

1
qoomon

Ich hatte viel mehr Glück beim lokalen Testen mit 127.0.0.1 als Domäne. Ich weiß nicht warum, aber ich hatte gemischte Ergebnisse mit localhost und .localhost usw.

1
toby

Es scheint ein Problem zu sein, wenn Sie https://<local-domain> und dann http://<local-domain> verwenden. Die http://-Site sendet keine Cookies mit Anforderungen, nachdem https://-Site sie festgelegt hat. Reload erzwingen und Cache leeren hilft nicht. Nur das manuelle Löschen von Cookies funktioniert. Wenn ich sie auf der Seite https:// lösche, funktioniert die Seite http:// wieder.

Sieht ähnlich aus wie "Strikte sichere Cookies". Gute Erklärung hier . Es wurde in Chrome 58 am 2017-04-19 veröffentlicht.

Es sieht so aus, als würde Chrome tatsächlich sowohl sichere Cookies als auch nicht sichere Cookies aufzeichnen, da beim Klicken auf das Adressleisten-Symbol abhängig vom Protokoll der Seite die richtigen Cookies angezeigt werden.

Developer tools > Application > Cookies zeigt jedoch kein nicht sicheres Cookie an, wenn für dieselbe Domain ein sicherer Cookie mit demselben Namen vorhanden ist, und es wird auch nicht das nicht sichere Cookie mit etwaigen Anforderungen senden. Dies scheint ein Chrome-Bug zu sein, oder wenn dieses Verhalten erwartet wird, sollte es eine Möglichkeit geben, die sicheren Cookies auf einer http-Seite anzuzeigen und darauf hinzuweisen, dass sie überschrieben werden.

Umgehung besteht darin, verschiedene benannte Cookies zu verwenden, je nachdem, ob sie sich auf eine http-Site oder eine https-Site beziehen, und diese für Ihre App spezifisch zu benennen. Ein __Secure--Präfix weist darauf hin, dass der Cookie streng sicher sein sollte. Dies ist auch eine bewährte Vorgehensweise, da sicheres und nicht sicheres Cookie nicht kollidieren. Es gibt andere Vorteile auch Präfixe.

Die Verwendung verschiedener /etc/hosts-Domänen für https vs. http-Zugriff würde ebenfalls funktionieren, aber ein zufälliger https://localhost-Besuch verhindert, dass Cookies mit den gleichen Namen auf http://localhost-Websites funktionieren. Daher ist dies keine gute Lösung.

Ich habe einen Chrome-Fehlerbericht eingereicht.

1
vaughan

Ich habe ein bisschen rumgespielt. 

Set-Cookie: _xsrf=2|f1313120|17df429d33515874d3e571d1c5ee2677|1485812120; Domain=localhost; Path=/

funktioniert ab heute in Firefox und Chrome. Ich habe jedoch keinen Weg gefunden, damit es mit curl funktioniert. Ich habe Host-Header ausprobiert und --resolve, kein Glück, jede Hilfe geschätzt.

Es funktioniert jedoch in curl, wenn ich es auf setze

Set-Cookie: _xsrf=2|f1313120|17df429d33515874d3e571d1c5ee2677|1485812120; Domain=127.0.0.1; Path=/

stattdessen. (Was mit Firefox nicht funktioniert.)

0
Micha

document.cookie = Wertname + "=" + Wert + ";" + verfällt + "; Domäne =; Pfad = /";

diese "Domäne =; Pfad = /"; nimmt dynamische Domain, da sein Cookie in der Subdomain funktioniert . Wenn Sie in localhost testen möchten, wird es funktionieren

0
Abhishek SInha

Es gibt ein Problem auf Chromium seit 2011 . Wenn Sie die Domäne explizit als 'localhost' festlegen, sollten Sie sie als false oder undefined festlegen.

0
Bruno Peres

Ein weiteres wichtiges Detail, das expires = sollte das folgende Datums-/Uhrzeitformat verwenden: Wdy, TT-Mo-JJJJ HH: MM: SS GMT ( RFC6265 - Abschnitt 4.1.1 ) .

Set-Cookie:
  name=value;
  domain=localhost;
  expires=Thu, 16-07-2019 21:25:05 GMT;
  path=/
0
Tralamazza

Wenn Sie ein Cookie aus einer anderen Domain setzen (dh Sie setzen das Cookie durch eine XHR-Cross-Origin-Anforderung), müssen Sie sicherstellen, dass Sie das withCredentials-Attribut in dem XMLHttpRequest-Attribut auf true setzen, das Sie zum Abrufen des Cookies verwenden, wie in _ beschrieben. Hier

0
Aidan Ewen

Ich hatte das gleiche Problem und habe es behoben, indem ich zwei Punkte in den Namen des Cookies gesetzt habe, ohne eine Domäne anzugeben.

set-cookie: name.s1.s2=value; path=/; expires=Sun, 12 Aug 2018 14:28:43 GMT; HttpOnly
0
Eric B.

Keine der Antworten funktionierte für mich. Ich habe das Problem behoben, indem ich PHP als erstes auf der Seite platzierte.

Wie andere Header müssen Cookies vor jeder Ausgabe Ihres Skripts gesendet werden (dies ist eine Protokolleinschränkung). Dies setzt voraus, dass Sie diese Funktion vor jeder Ausgabe aufrufen, einschließlich und Tags sowie Leerzeichen.

Von http://php.net/manual/de/function.setcookie.php

0
john ktejik