Файлы cookie на локальном хосте с явным доменом - PullRequest
Новая
       72

Файлы cookie на локальном хосте с явным доменом

163 голосов
/ 16 июля 2009

Я, должно быть, скучаю по некоторым элементам cookie. На localhost, когда я устанавливаю cookie на стороне сервера, и явно указывают домен как localhost (или .localhost). cookie не принимается некоторыми браузерами.

Firefox 3.5: Я проверил HTTP-запрос в Firebug. То, что я вижу: 

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

или (когда я устанавливаю домен в .localhost): 

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

В любом случае файл cookie не сохраняется.

IE8: Я не использовал никаких дополнительных инструментов, но файл cookie, похоже, также не сохраняется, поскольку в последующих запросах он не отправляется обратно.

Opera 9.64: И localhost, и .localhost работают , но когда я проверяю список файлов cookie в настройках, домен получает значение localhost.local, даже если он указан в списке localhost. (в списке группировки).

Safari 4: И localhost, и .localhost работают , но они всегда указаны как .localhost в настройках. С другой стороны, cookie без явного домена, он отображается как просто localhost (без точки).

В чем проблема с localhost? Из-за такого количества несоответствий должны быть некоторые специальные правила, касающиеся localhost. Кроме того, мне не совсем понятно, почему домены должны начинаться с префикса? RFC 2109 прямо заявляет, что:

Значение атрибута домена не содержит встроенных точек или не содержит начать с точки.

Почему? В документе указывается, что это связано с безопасностью. Я должен признать, что я не прочитал всю спецификацию (возможно, сделаю это позже), но это звучит немного странно. Исходя из этого, установка куки на localhost будет невозможна.

Ответы [ 17 ]

210 голосов
/ 27 июля 2009

По своему дизайну доменные имена должны иметь как минимум две точки; в противном случае браузер сочтет их недействительными. (См. Ссылку на http://curl.haxx.se/rfc/cookie_spec.html)

При работе с localhost домен cookie должен быть полностью опущен. Недостаточно просто установить "" или NULL или FALSE вместо "localhost".

Для PHP см. Комментарии к http://php.net/manual/en/function.setcookie.php#73107.

Если вы работаете с Java Servlet API, вообще не вызывайте метод cookie.setDomain("...").

29 голосов
/ 20 мая 2013

Я в целом согласен с @Ralph Buchfelder, но вот несколько примеров, когда я пытаюсь воспроизвести систему с несколькими поддоменами (например, example.com, fr.example.com, de.example.com) на моем эксперименте. локальный компьютер (OS X / Apache / Chrome | Firefox).

Я отредактировал / etc / hosts, чтобы указать несколько воображаемых поддоменов на 127.0.0.1:

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

Если я работаю на fr.localexample.com и не указываю параметр домена, файл cookie правильно сохраняется для fr.localexample.com, но не отображается в других поддоменах.

Если я использую домен ".localexample.com", файл cookie правильно сохраняется для fr.localexample.com, а виден в других поддоменах.

Если я использую домен "localexample.com" или когда я пытался использовать домен только "localexample" или "localhost", файл cookie не сохранялся.

Если я использую домен "fr.localexample.com" или ".fr.localexample.com", файл cookie правильно сохраняется для fr.localexample.com и (правильно) невидим в других поддоменах.

Таким образом, требование, чтобы вам было необходимо как минимум две точки в домене, кажется правильным, хотя я не понимаю, почему это так.

Если кто-то хочет попробовать это, вот несколько полезных кодов: 

<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 "
"; ?>
27 голосов
/ 27 февраля 2014

localhost: Вы можете использовать: domain: ".app.localhost", и это будет работать. Параметру 'domain' требуется 1 или более точек в имени домена для настройки файлов cookie. Тогда у вас могут быть сеансы, работающие в поддоменах localhost, например: api.app.localhost:3000.

11 голосов
/ 25 августа 2015

Когда файл cookie установлен с явным доменом 'localhost' следующим образом ...

Set-Cookie: имя = значение; домен = локальный ; истекает = четверг, 16 июля 2009 21:25:05 GMT; путь = /

... тогда браузеры игнорируют его, потому что он не включает как минимум два периода и не является одним из семи специально обработанных доменов верхнего уровня .

... домены должны иметь по крайней мере два (2) или три (3) периода в них запрещать домены в форме: ".com", ".edu" и "va.us". Любой домен который не работает в одном из семи перечисленных специальных доменов верхнего уровня ниже требуется только два периода. Любой другой домен требует как минимум три. Семь специальных доменов верхнего уровня: «COM», «EDU», «NET», "ORG", "GOV", "MIL" и "INT".

Обратите внимание, что число периодов выше, вероятно, предполагает, что требуется ведущий период. Однако этот период игнорируется в современных браузерах , и, вероятно, его следует читать ...

не менее один (1) или два (2) периода

Обратите внимание, что значением по умолчанию для атрибута домена является имя хоста сервера, который сгенерировал ответ файла cookie .

Итак, Обходной путь для файлов cookie, которые не устанавливаются для localhost, состоит в том, чтобы просто не указывать атрибут домена и позволить браузеру использовать значение по умолчанию - это, похоже, не имеет тех же ограничений, что и явное значение Атрибут домена делает.

3 голосов
/ 23 августа 2012

Результаты, которые я изменил в браузере.

Chrome - 127.0.0.1 работал, но localhost .localhost и "" не работали. Firefox- .localhost работал, но localhost, 127.0.0.1 и "" не работали.

Не тестировали в Opera, IE или Safari

2 голосов
/ 15 декабря 2016

Сам потратил много времени на устранение этой проблемы.

Использование PHP, и ничего на этой странице не работает для меня. В конце концов я понял в своем коде, что параметр «secure» для session_set_cookie_params () PHP всегда был установлен в TRUE.

Поскольку я не посещал localhost с https, мой браузер никогда не будет принимать cookie. Итак, я изменил эту часть своего кода, чтобы условно установить параметр «secure», основываясь на том, что $ _SERVER ['HTTP_HOST'] равен 'localhost' или нет. Работает хорошо сейчас.

Надеюсь, это кому-нибудь поможет.

1 голос
/ 05 ноября 2014

Ни одно из предложенных исправлений не сработало для меня - установка его на ноль, ложь, добавление двух точек и т. Д. - не сработала.

В итоге я просто удалил домен из куки, если это localhost, и теперь он работает для меня в Chrome 38 .

Предыдущий код (не работал): 

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

Новый код (теперь работает): 

 if(document.domain === 'localhost') {
        document.cookie = encodeURI(key) + '=' + encodeURI(value) + ';path=/;' ;
    } else {
        document.cookie = encodeURI(key) + '=' + encodeURI(value) + ';domain=.' + document.domain + ';path=/;';
    }
1 голос
/ 01 апреля 2012

Мне повезло, когда я тестировал локально, используя 127.0.0.1 в качестве домена. Я не уверен почему, но у меня были смешанные результаты с localhost и .localhost и т. Д.

1 голос
/ 27 марта 2019

вы можете использовать localhost.org или, скорее, .localhost.org, оно всегда будет разрешаться до 127.0.0.1

1 голос
/ 14 мая 2018

Кажется, есть проблема, когда вы используете https://<local-domain>, а затем http://<local-domain>. Сайт http:// не отправляет файлы cookie с запросами после того, как сайт https:// их установил. Принудительная перезагрузка и очистка кеша не помогают. Работает только ручная очистка куки. Кроме того, если я очищу их на странице https://, то страница http:// снова начнет работать.

Похоже, что связано с "Строгие безопасные куки". Хорошее объяснение здесь . Это был , выпущенный в Chrome 58 2017-04-19.

Похоже, что на самом деле Chrome записывает как безопасные, так и небезопасные файлы cookie, поскольку при нажатии на значок в адресной строке будут отображаться правильные файлы cookie в зависимости от протокола страницы.

Но Developer tools > Application > Cookies не будет отображать небезопасный файл cookie, когда есть безопасный файл cookie с тем же именем для того же домена, и не будет отправлять незащищенный файл cookie с любыми запросами. Это похоже на ошибку Chrome, или, если такое поведение ожидается, должен быть какой-то способ просмотра защищенных файлов cookie на странице http и указания, что они переопределяются.

Обходной путь - использовать разные именованные куки-файлы в зависимости от того, предназначены ли они для http-сайта или https-сайта, и называть их в соответствии с вашим приложением. Префикс __Secure- указывает на то, что файл cookie должен быть строго защищенным, а также является хорошей практикой, поскольку безопасные и небезопасные не конфликтуют. Для префиксов есть другие преимущества .

Использование разных доменов /etc/hosts для https и http-доступа также будет работать, но одно случайное посещение https://localhost предотвратит работу файлов cookie с одинаковыми именами на http://localhost сайтах, так что это не хороший обходной путь.

Я подал Отчет об ошибке Chrome .

Страница:
...