Pliki cookie na localhost z jawną domeną

191

Brakuje mi podstawowych informacji na temat plików cookie. Na localhost, kiedy ustawiam plik cookie po stronie serwera i wyraźnie określam domenę jako localhost (lub .localhost). plik cookie nie jest akceptowany przez niektóre przeglądarki.

Firefox 3.5: Sprawdziłem żądanie HTTP w Firebug. Widzę to:

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

lub (kiedy ustawię domenę na .localhost):

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

W obu przypadkach plik cookie nie jest przechowywany.

IE8: Nie korzystałem z żadnego dodatkowego narzędzia, ale plik cookie również nie jest przechowywany, ponieważ nie jest wysyłany z powrotem w kolejnych żądaniach.

Opera 9.64: Zarówno localhost i .localhost praca , ale kiedy sprawdzić listę cookies w preferencji, domena jest ustawiony na localhost.local mimo to wymienione w localhost (na liście grupy).

Safari 4: Zarówno localhost i .localhost praca , ale zawsze są one wymienione jako .localhost w preferencjach. Z drugiej strony plik cookie bez wyraźnej domeny, wyświetlany jako zwykły host (bez kropki).

W czym problem z localhost? Z powodu takiej liczby niespójności muszą istnieć specjalne zasady dotyczące hosta lokalnego. Ponadto nie jest dla mnie całkowicie jasne, dlaczego domeny muszą być poprzedzone kropką? RFC 2109 wyraźnie stwierdza, że:

Wartość atrybutu Domain nie zawiera osadzonych kropek lub nie zaczyna się od kropki.

Czemu? Dokument wskazuje, że ma coś wspólnego z bezpieczeństwem. Muszę przyznać, że nie przeczytałem całej specyfikacji (może zrobić to później), ale brzmi to trochę dziwnie. Na tej podstawie ustawienie plików cookie na localhost byłoby niemożliwe.

cookies setcookie Jan Zich
źródło

14

6-letni wątek i to wciąż stanowi problem. Używam Chrome v40. Zobacz tutaj .

Gaui

5

Chrome 43 ... wciąż błąd.

Evan Carroll,

4

Chrome 54 tutaj, NIE rozwiązany

Vahid Amiri

6

Chrome 73 .. wciąż napotyka ten sam problem. :(

Code_Crash

2

Czy ktoś może to rozwiązać? Wciąż

mam

236

Z założenia nazwy domen muszą mieć co najmniej dwie kropki; w przeciwnym razie przeglądarka uzna je za nieprawidłowe. (Zobacz odniesienie na http://curl.haxx.se/rfc/cookie_spec.html )

Podczas pracy localhostdomenę plików cookie należy całkowicie pominąć. Wystarczy ustawić go w pozycji ""lub NULLczy FALSEzamiast "localhost"nie wystarczy.

W przypadku PHP zobacz komentarze na http://php.net/manual/en/function.setcookie.php#73107 .

Jeśli pracujesz z API Java Servlet API, w ogóle nie wywoływaj tej cookie.setDomain("...")metody.

Ralph Buchfelder
źródło

93

Nie jestem pewien, dlaczego wszyscy dają +1, ustawiłem domenę ciasteczka na null lub false lub pusty ciąg i nadal nie zapisuje się, jeśli na localhost.

Justin

5

Nigdzie w RFC6265 nie widzę dwóch kropek w domenie: tools.ietf.org/html/rfc6265#section-5.2.3 .Net mówi, aby ustawić na „.local” dla wszystkich hostów w domenie lokalnej. Co wydaje się zgodne z Opera / Safari msdn.microsoft.com/en-us/library/ckch3yd2.aspx

MandoMando

9

@Justin: Hm, prawdopodobnie musisz całkowicie pominąć Domain=parametr podczas ustawiania ciasteczka. Jeśli po prostu ustawisz domenę na null lub pustą, być może Twoja struktura wyśle Domain=parametr o tej wartości, zamiast go pominąć? Sprawdź np. Firebug.

sleske

2

@Ralph, milion dzięki, ta sprawa doprowadzała mnie do szaleństwa przez kilka godzin. Mam nadzieję, że ustawienie Domeny na null (jestem na stosie serwerów .Net) działa jak urok.

Xose Lluis

4

Jest to nieco źle sformułowane. „Ustawienie pustego lub fałszywego lub pustego ciągu” powinno brzmieć „W ogóle nie ustawia się ciasteczka w domenie”. Na przykład za pomocą prostego testu, aby całkowicie pominąć sekcję domenową pliku cookie, działa dla hosta lokalnego:((domain && domain !== "localhost") ? ";domain="+domain : "")

L0j1k

34

Zasadniczo zgadzam się z @Ralphem Buchfelderem, ale oto pewne wzmocnienie tego, eksperymentując podczas próby replikacji systemu z kilkoma poddomenami (np. Example.com, fr.example.com, de.example.com) na mojej lokalnej maszynie ( OS X / Apache / Chrome | Firefox).

Edytowałem / etc / hosts, aby wskazać niektóre wymyślone poddomeny na 127.0.0.1:

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

Jeśli pracuję nad fr.localexample.com i pozostawiam parametr domeny wyłączony, plik cookie jest przechowywany poprawnie dla fr.localexample.com, ale nie jest widoczny w innych subdomenach.

Jeśli używam domeny „.localexample.com”, plik cookie jest przechowywany poprawnie dla fr.localexample.com i jest widoczny w innych subdomenach.

Jeśli korzystam z domeny „localexample.com” lub gdy próbowałem domeny „localexample” lub „localhost”, plik cookie nie był zapisywany.

Jeśli użyję domeny „fr.localexample.com” lub „.fr.localexample.com”, plik cookie jest przechowywany poprawnie dla fr.localexample.com i jest (poprawnie) niewidoczny w innych subdomenach.

Zatem wymóg, że potrzebujesz co najmniej dwóch kropek w domenie, wydaje się poprawny, nawet jeśli nie rozumiem, dlaczego tak jest.

Jeśli ktoś chce to wypróbować, oto przydatny kod:

<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>

Xgretsch
źródło

30

localhost: Możesz użyć: domain: ".app.localhost"i będzie działać. Parametr „domena” wymaga co najmniej 1 kropki w nazwie domeny do ustawienia plików cookie. Wtedy można mieć sesje robocze subdomen localhost, takich jak: api.app.localhost:3000.

AmpT
źródło

1

Przetestowano również i działa na serwerze node.js przy użyciu Express 3.x, wexpress.session({cookie: { domain: '.app.localhost', maxAge: 24 * 60 * 60 * 1000 }})

AmpT

3

TO powinno być wybrane jako odpowiedź, jeśli używasz domen lokalnych! Umieszczenie kropki przed poddomeną rozwiązuje mój problem.

Foxhoundn

1

Skąd więc to dopływanie .app.? Czy to część jakiegoś SPEC? I czy ma to zastosowanie do wszystkich domen niezgodnych (tych bez dwóch kropek)? Czy to również będzie działać ze starymi przeglądarkami? : ^)

user2173353

Och ... Rozumiem teraz ... To tylko podstęp, by oszukać przeglądarki. DOBRZE.

user2173353

14

Gdy plik cookie ma ustawioną wyraźną domenę „localhost” w następujący sposób ...

Zestaw plików cookie: nazwa = wartość; domena = host lokalny ; wygasa = czw., 16-lip-2009 21:25:05 GMT; ścieżka = /

... to przeglądarki go ignorują, ponieważ nie zawiera co najmniej dwóch kropek i nie jest jedną z siedmiu specjalnie obsługiwanych domen najwyższego poziomu .

... domeny muszą mieć co najmniej dwa (2) lub trzy (3) okresy, aby zapobiec domenom w postaci: „.com”, „.edu” i „va.us”. Każda domena, która zawodzi w jednej z siedmiu specjalnych domen najwyższego poziomu wymienionych poniżej, wymaga tylko dwóch okresów. Każda inna domena wymaga co najmniej trzech. Siedem specjalnych domen najwyższego poziomu to: „COM”, „EDU”, „NET”, „ORG”, „GOV”, „MIL” i „INT”.

Należy pamiętać, że liczba okresów powyżej prawdopodobnie zakłada, że wymagany jest okres wiodący. Ten okres jest jednak ignorowany w nowoczesnych przeglądarkach i prawdopodobnie powinien przeczytać ...

co najmniej jeden (1) lub dwa (2) okresy

Zauważ, że domyślną wartością atrybutu domain jest nazwa hosta serwera, który wygenerował odpowiedź cookie .

Tak więc obejściem dla plików cookie, które nie są ustawione dla hosta lokalnego, jest po prostu brak określenia atrybutu domeny i umożliwienie przeglądarce użycia wartości domyślnej - nie wydaje się, że ma takie same ograniczenia, jak jawna wartość w atrybucie domeny.

Scott Munro
źródło

Nie nagrałem DV, ale zgaduję, że powodem, dla którego inni to zrobili, jest to, że twoja odpowiedź tak naprawdę nie dodaje dużej wartości. Oba wymagania dotyczące dwóch okresów i pozostawienie pustego atrybutu domeny zostały omówione w innych odpowiedziach. Ponadto rzeczy dodane do domeny najwyższego poziomu wydają się niepoprawne. Z mojego doświadczenia wynika, że nie jest to wymóg.

TTT

@TTT Nie jestem pewien, czy dotarłeś do mojego fragmentu w mojej odpowiedzi, gdzie mówię, że powinien to być co najmniej 1 lub 2 okresy w zależności od TLD, ponieważ okresy wiodące są ignorowane? Podałem więc trochę informacji o problemie i dodałem punkt, który moim zdaniem nie jest omawiany gdzie indziej - zasady są różne dla jawnej domeny i tej, którą domyślnie ma przeglądarka. Wygląda na to, że dodaje mi to pewnej wartości.

Scott Munro

1

Pozostawienie domeny zerowej (nie ustawianie jej wcale) NIE powoduje, że Chrome zachowuje plik cookie dla hosta lokalnego. Nadal to ignoruje. Pamiętaj, że dotyczy to tylko „trwałych” plików cookie (tych, które ustawiają datę ważności), ponieważ będą się zawieszać na „sesyjnych” plikach cookie dla hosta lokalnego (tych, które nie ustawiają daty ważności).

Triynko

3

Wyniki różniłem się w zależności od przeglądarki.

Chrome-127.0.0.1 działał, ale localhost .localhost i „” nie. Firefox- .localhost działał, ale localhost, 127.0.0.1, i „” nie.

Nie testowałem w Operze, IE ani Safari

źródło

3

Właśnie przetestowałem to z Chrome V.22.0.1229.94 m: Ustawienie pliku cookie dla hosta lokalnego bez podania Domain=parametru działa. Domain=działa również, ale Domain=localhostnie działa.

sleske

3

Sam spędziłem dużo czasu na rozwiązywaniu tego problemu.

Używanie PHP i nic na tej stronie nie działało dla mnie. W końcu zdałem sobie sprawę z mojego kodu, że parametr „bezpieczny” dla PHP session_set_cookie_params () zawsze był ustawiony na PRAWDA.

Ponieważ nie odwiedzałem localhost z https, moja przeglądarka nigdy nie zaakceptuje ciasteczka. Zmodyfikowałem więc tę część mojego kodu, aby warunkowo ustawić parametr „bezpieczny” na podstawie $ _SERVER [„HTTP_HOST”] jako „localhost” lub nie. Teraz działa dobrze.

Mam nadzieję, że to komuś pomoże.

James Jacobson
źródło

2

Jeśli ustawiasz plik cookie z innej domeny (tj. Ustawiasz plik cookie, przesyłając żądanie XHR do krzyżowego pochodzenia), musisz upewnić się, że ustawiłeś withCredentialsatrybut na true w XMLHttpRequest, którego używasz do pobierania pliku cookie, jak opisano tutaj

Aidan Ewen
źródło

tak, nawet z tym. Nadal nie działa z żądaniami między domenami. Przeglądarka - Safari, IE 11

Rohit Kumar

2

możesz skorzystać, localhost.orga raczej .localhost.orgzawsze to rozwiąże127.0.0.1

qoomon
źródło

1

Miałem dużo więcej szczęścia testując lokalnie, używając 127.0.0.1 jako domeny. Nie jestem pewien dlaczego, ale miałem mieszane wyniki z localhost i .localhost itp.

Toby
źródło

1

Żadna z sugerowanych poprawek nie działała dla mnie - ustawienie na zero, fałsz, dodanie dwóch kropek itp. - nie działało.

W końcu właśnie usunąłem domenę z pliku cookie, jeśli jest to host lokalny, a teraz działa dla mnie w Chrome 38 .

Poprzedni kod (nie działał):

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

Nowy kod (teraz działa):

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

DJ_Polly
źródło

1

Miałem ten sam problem i naprawiłem go, umieszczając 2 kropki w samej nazwie pliku cookie bez określania domeny.

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

Eric B.
źródło

1

Wydaje się, że występuje problem podczas używania, https://<local-domain>a następnie http://<local-domain>. http://Strona nie wysyłać ciasteczka z wniosków po https://zestawów je na miejscu. Wymuszanie przeładowania i czyszczenie pamięci podręcznej nie pomaga. Działa tylko ręczne czyszczenie plików cookie. Ponadto, jeśli wyczyszczę je na https://stronie, http://strona zacznie ponownie działać.

Wygląda na związane z „ścisłymi bezpiecznymi plikami cookie”. Dobre wyjaśnienie tutaj . Został wydany w Chrome 58 19.04.2017.

Wygląda na to, że Chrome faktycznie rejestruje zarówno bezpieczne, jak i niezabezpieczone pliki cookie, ponieważ wyświetla prawidłowe pliki cookie w zależności od protokołu strony po kliknięciu ikony paska adresu.

Ale Developer tools > Application > Cookiesnie pokaże niezabezpieczonego pliku cookie, gdy istnieje bezpieczny plik cookie o tej samej nazwie dla tej samej domeny, ani nie wyśle niezabezpieczonego pliku cookie z żądaniami. Wydaje się, że to błąd przeglądarki Chrome lub jeśli takie zachowanie jest oczekiwane, powinien istnieć sposób na przeglądanie bezpiecznych plików cookie na httpstronie i wskazanie, że są one zastępowane.

Obejściem tego problemu jest używanie różnych nazwanych plików cookie w zależności od tego, czy dotyczą one witryny http, czy https, oraz nazywanie ich specyficznych dla aplikacji. __Secure-Przedrostek wskazuje, że ciasteczka powinny być ściśle strzeżony, a także jest to dobra praktyka, ponieważ bezpieczne i niezabezpieczone nie zderzą. Są też inne korzyści z prefiksów.

Korzystanie z różnych /etc/hostsdomen dla dostępu https vs. http również działałoby, ale jedna przypadkowa https://localhostwizyta uniemożliwi działanie plików cookie o tych samych nazwach w http://localhostwitrynach - więc nie jest to dobre obejście.

I złożyli raport o błędzie Chrome .

Vaughan
źródło

0

document.cookie = nazwa wartości + "=" + wartość + ";" + wygasa + "; domena =; ścieżka = /";

ta „domena =; ścieżka = /”; zajmie domenę dynamiczną, ponieważ jej plik cookie będzie działał w subdomenie. jeśli chcesz przetestować na localhost, to zadziała

Abhishek SInha
źródło

0

Żadna z odpowiedzi tutaj nie działała dla mnie. Naprawiłem to, umieszczając mój PHP jako pierwszą rzecz na stronie.

Podobnie jak inne nagłówki, pliki cookie muszą być wysyłane przed wyjściem ze skryptu (jest to ograniczenie protokołu). Wymaga to umieszczenia wywołań tej funkcji przed jakimkolwiek wyjściem, włączając w to tagi i dowolne białe znaki.

Od http://php.net/manual/en/function.setcookie.php

John KTejik
źródło

nie ma to jednak nic wspólnego z tym problemem, to po prostu nie popełnianie błędu wysyłania innych danych wyjściowych przed nagłówkami

Marnes

0

Od 2011 r. W Chromium występuje problem polegający na tym, że jeśli jawnie ustawiasz domenę jako „localhost”, powinieneś ustawić ją jako falselub undefined.

Bruno Peres
źródło

0

Bawiłem się trochę.

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

działa w Firefox i Chrome od dziś. Nie znalazłem jednak sposobu, aby to działało z zawijaniem. Próbowałem Host-Header i - rozwiązać, bez powodzenia, doceniłem każdą pomoc.

Działa to jednak w zwijaniu, jeśli ustawię to na

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

zamiast. (Który nie działa z Firefoksem.)

Micha
źródło

0

Kolejny ważny szczegół: data ważności = powinna używać następującego formatu daty i godziny: Wdy, DD-Pn-RRRR GG: MM: SS GMT ( RFC6265 - sekcja 4.1.1 ).

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

Tralamazza
źródło

5

-1 Obecna specyfikacja plików cookie to RFC 6265, tools.ietf.org/html/rfc6265 , która wyraźnie stwierdza, że dozwolone są 4-cyfrowe lata. Dlatego złym pomysłem jest używanie 2-cyfrowych lat, które różne przeglądarki będą interpretować inaczej.

sleske

Poprawny. Odwołaj się do RFC6265 sekcja 4.1.1

Wózek Zen

4

Zgadza się, ale w czerwcu 2011 roku nie znalazłem tego RFC. Chociaż te informacje są teraz niepoprawne, w przeszłości, kiedy je pisałem, nie były.

Tralamazza

4

Nie bierz tego za drobiazg, wszystko się zmienia i wszyscy musimy pomóc, aby odpowiedzi były aktualne. Po prostu zaktualizuj swoją odpowiedź o najnowsze informacje, które przekazał ci @sleske i podziękuj mu za pomoc.

Matthew Purdon,

0

Po wielu eksperymentach i przeczytaniu różnych postów zadziałało. Mogłem ustawić wiele plików cookie, odczytać je z powrotem, ustawić czas ujemny i usunąć je.

func addCookie(w http.ResponseWriter, name string, value string) {
    expire := time.Now().AddDate(0, 0, 1)
    cookie := http.Cookie{
       Name:    name,
       Value:   value,
       Expires: expire,
       Domain:  ".localhost",
       Path:    "/",
    }
    http.SetCookie(w, &cookie)
}

Saied
źródło

0

Jedyną rzeczą, która działała dla mnie, było ustawienie Path=/pliku cookie.

Co więcej, domyślna wartość atrybutu path wydaje się różnić od przeglądarki do przeglądarki, chociaż przetestowałem tylko dwie z nich (Firefox i Chrome).

Chrome próbuje ustawić plik cookie bez zmian; jeśli pathatrybut zostanie pominięty w Set-Cookienagłówku, nie zostanie zapisany i zignorowany.

Jednak Firefox przechowuje plik cookie nawet bez wyraźnego pathatrybutu. Po prostu ustawia żądaną ścieżkę; mój adres URL żądania /api/v1/usersbył ustawiony i ścieżka była ustawiona /api/v1automatycznie.

W każdym razie obie przeglądarki działały, gdy pathustawiono je na /nawet bez wyraźnej domeny, czyli Domain=localhostczegoś takiego. Istnieją więc pewne różnice w sposobie obsługi plików cookie przez każdą przeglądarkę.

이준형
źródło

Pliki cookie na localhost z jawną domeną

Odpowiedzi: