Файли cookie у localhost з явним доменом

191

Мені, мабуть, не вистачає основної речі про куки. У 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 прямо вказує, що:

Значення для атрибута Domain не містить вбудованих точок або не починається з крапки.

Чому? У документі вказується, що він повинен щось робити із захистом. Мушу визнати, що я не прочитав усю специфікацію (можливо, це пізніше), але це звучить трохи дивно. Виходячи з цього, встановити cookie на localhost було б неможливо.

cookies  setcookie 
— Ян Зіх
джерело
14
6 років, нитка, і це все ще є проблемою. Я використовую Chrome v40. Дивіться тут .
— Gaui
5
Chrome 43 ... все-таки помилка.
— Еван Керролл
4
Chrome 54 тут, НЕ вирішено
— Вахід Амірі
6
Chrome 73 .. все ще стикається з тією ж проблемою. :(
— Code_Crash
2
Хтось міг це вирішити? Тим НЕ менше стикаються з тими ж S *** .. побачити цей SO відповідь
— Bonjour123

Відповіді:

236

За дизайном доменні імена повинні мати не менше двох крапок; інакше браузер вважатиме їх недійсними. (Див. Посилання на http://curl.haxx.se/rfc/cookie_spec.html )

Під час роботи над localhostдоменом cookie потрібно повністю пропустити. Просто встановивши його ""або NULLабо FALSEзамість "localhost"цього недостатньо.

Про PHP дивіться коментарі на http://php.net/manual/en/function.setcookie.php#73107 .

Якщо ви працюєте з API сервлетів Java, взагалі не викликайте cookie.setDomain("...")метод.

— Ральф Бухфельдер
джерело
93
Не впевнений, чому всі ставлять +1, це я встановив домен файлу cookie на нульовій чи помилковій чи порожній рядку, і він все ще не зберігається, якщо на localhost.
— Джастін
5
Я не бачу ніде в RFC6265 про дві точки в домені: tools.ietf.org/html/rfc6265#section-5.2.3. Net говорить, що встановіть його на ".local" для всіх хостів у вашому локальному домені. Що здається сумісним з Opera / Safari msdn.microsoft.com/en-us/library/ckch3yd2.aspx
— MandoMando
9
@Justin: Хм, вам, ймовірно, потрібно повністю опустити Domain=параметр під час встановлення файлу cookie. Якщо ви просто встановите домен на нуль або порожній, можливо, ваша рамка надішле Domain=параметр із цим значенням, а не опустіть його? Перевірте, наприклад, Firebug.
— sleske
2
@ Ralph, мільйон подяк, ця річ зводила мене з розуму протягом кількох годин. Сподіваємось, що встановлення Домену на нульове значення (я в стеку сервера .Net) працює як принадність.
— Xose Lluis
4
Це дещо погано сформульовано. "Установка на нульову або помилкову або порожню рядок" повинна містити повідомлення "Не встановлюючи частину файлу cookie" домен "взагалі". Наприклад, використовуючи простий тест, щоб повністю вийти з доменного розділу файлу cookie працює для localhost:((domain && domain !== "localhost") ? ";domain="+domain : "")
— L0j1k
34

Я широко погоджуюся з @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», печиво правильно зберігатися fr.localexample.com, і це видно в інших піддоменів.

Якщо я використовую домен "localexample.com" або коли я намагався домен просто "localexample" або "localhost", файл cookie не зберігався.

Якщо я використовую домен "fr.localexample.com" або ".fr.localexample.com", файл cookie зберігається правильно для fr.localexample.com і є (правильно) невидимим для інших субдоменів.

Отже, вимога про те, що вам потрібно принаймні дві точки в домені, видається правильною, хоча я не можу зрозуміти, чому це має бути.

Якщо хтось хоче спробувати це, ось вам корисний код:

<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
джерело
30

localhost: Ви можете використовувати: domain: ".app.localhost"і він буде працювати. Параметр "домен" потребує 1 або більше крапок у доменному імені для встановлення файлів cookie. Тоді ви можете мати сеанси роботи через локальні піддомени , такі як: api.app.localhost:3000.

— AmpT
джерело
1
Також тестовано і працює на сервері node.js, використовуючи Express 3.x, вexpress.session({cookie: { domain: '.app.localhost', maxAge: 24 * 60 * 60 * 1000 }})
— AmpT
3
ЦЕ слід обрати як відповідь, якщо ви використовуєте локальні домени! Поставлення крапки перед субдоменом вирішує мою проблему.
— Фоксхаундн
1
Отже, звідки це передчуття .app.пришестя? Це частина якоїсь SPEC? І чи застосовна вона для всіх невідповідних доменів (тих, які не мають двох крапок)? Також це буде працювати зі старими браузерами? : ^)
— user2173353
Ох ... я зараз розумію ... Це лише хитрість обдурити браузери. ГАРАЗД.
— user2173353
14

Коли cookie встановлено з явним доменом "localhost", наступним чином ...

Set-Cookie: ім'я = значення; домен = localhost ; закінчується = Чт, 16 липня 2009 21:25:05 GMT; шлях = /

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

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

Зауважте, що кількість періодів вище, ймовірно, передбачає необхідний провідний період. Цей період, однак, ігнорується в сучасних браузерах, і він, ймовірно, повинен читати ...

принаймні один (1) або два (2) періоди

Зауважте, що за замовчуванням для доменного атрибута є ім'я хоста сервера, який генерував відповідь на cookie .

Тож вирішення файлів cookie, не встановлених для localhost, полягає в тому, щоб просто не вказати атрибут домену та дозволити браузеру використовувати значення за замовчуванням - це, мабуть, не має тих самих обмежень, що і явне значення в атрибуті домену.

— Скотт Манро
джерело
Я не робив DV, але я здогадуюсь, що причина це зробили інші, тому що ваша відповідь насправді не додає великої цінності. Вимоги двох періодів та залишення атрибута домену порожнім обговорювалися в інших відповідях. Крім того, дані, які ви додали про домен верхнього рівня, здаються неправильними. На мій досвід, це не є вимогою.
— TTT
@TTT Не впевнений, якщо ви потрапили на біт у моїй відповіді, де я кажу, що це має бути принаймні 1 або два періоди залежно від TLD, оскільки провідні періоди ігноруються? Тож я подав деяку інформацію про проблему та додав пункт, який, на мою думку, не стосується в іншому місці - правила відрізняються для явного домену та того, для якого браузер за замовчуванням. Здається, це додає мені певної цінності.
— Скотт Манро
1
Залишаючи домен null (не встановлюючи його зовсім), НЕ спричиняє Chrome зберігати файл cookie для localhost. Це все ще ігнорує. Зауважте, що це стосується лише "постійних" файлів cookie (тих, які встановлюють дату закінчення терміну дії), оскільки вони будуть зависати для "сеансових" файлів cookie для localhost (тих, у яких не встановлено дату закінчення терміну дії).
— Трайнко
3

Результати у мене були різними в браузері.

Chrome- 127.0.0.1 працював, але localhost .localhost та "" не зробили. Firefox- .localhost працював, але localhost, 127.0.0.1, і "" цього не робив.

Не проходили тестування в Opera, IE або Safari

3
Щойно тестовано це за допомогою Chrome V.22.0.1229.94 м. Налаштування файлу cookie для localhost без надання Domain=параметра працює. Domain=також працює, але Domain=localhostне робить.
— sleske
3

Я витратив чимало часу на вирішення цієї проблеми сам.

Використання PHP і нічого на цій сторінці не працювало для мене. Зрештою, я зрозумів у своєму коді, що параметр 'secure' для PHP's session_set_cookie_params () завжди встановлювався як TRUE.

Оскільки я не відвідував localhost з https, браузер ніколи не прийме файли cookie. Отже, я змінив цю частину свого коду, щоб умовно встановити «захищений» парам на основі $ _SERVER ['HTTP_HOST'], будучи «localhost» чи ні. Зараз добре працює.

Я сподіваюся, що це комусь допоможе.

— Джеймс Джейкобсон
джерело
2

Якщо ви встановлюєте файл cookie з іншого домену (тобто ви встановлюєте файл cookie, роблячи запит перехресного походження XHR), тоді вам потрібно переконатися, що ви встановили withCredentialsатрибут true на XMLHttpRequest, який ви використовуєте для отримання файлу cookie, як описано тут

— Айдан Евен
джерело
так, навіть при тому. Він все ще не працює з міждоменними запитами. Браузер - Safari, IE 11
— Рохіт Кумар
2

ви можете скористатися, localhost.orgа точніше, .localhost.orgце завжди вирішуватиметься127.0.0.1

— qoomon
джерело
1

Я мав набагато більше удачі на місцевому тестуванні, використовуючи 127.0.0.1 як домен. Я не знаю чому, але я мав змішані результати з localhost та .localhost тощо.

— тобі
джерело
1

Жоден із запропонованих виправлень не працював для мене - встановлення його на "null", "false", додавання двох крапок тощо - не працювало.

Зрештою, я просто видалив домен із файлу cookie, якщо він є 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=/;';
    }
— DJ_Polly
джерело
1

У мене була та сама проблема, і я її виправив, ввівши 2 крапки в ім’я файлу cookie, не вказуючи домен.

set-cookie: name.s1.s2=value; path=/; expires=Sun, 12 Aug 2018 14:28:43 GMT; HttpOnly
— Ерік Б.
джерело
1

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

Схоже, пов’язане із "Суворими безпечними файлами cookie". Хороше пояснення тут . Він був випущений у Chrome 58 2017-04-19.

Схоже, Chrome насправді записує як захищені файли cookie, так і незахищені файли cookie, оскільки вони показуватимуть правильні файли cookie залежно від протоколу сторінки при натисканні піктограми адресного рядка.

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

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

Використання різних /etc/hostsдоменів для https та http доступу також буде працювати, але один випадковий https://localhostвізит не дозволить файлам cookie з однаковими іменами працювати на http://localhostсайтах - тож це не дуже вдале рішення.

Я подав звіт про помилку в Chrome .

— вуан
джерело
0

document.cookie = valuename + "=" + значення + ";" + закінчується + "; домен =; шлях = /";

цей "домен =; шлях = /"; буде приймати динамічний домен, оскільки його cookie буде працювати в піддомені. якщо ти хочеш протестувати в localhost, він буде працювати

— Абхішек С.І.
джерело
0

Жодна з відповідей тут не працювала на мене. Я виправив це, поставивши свій PHP як найперше на сторінці.

Як і інші заголовки, файли cookie повинні надсилатися перед будь-яким виведенням із вашого сценарію (це обмеження у протоколі). Для цього потрібно здійснити виклики до цієї функції перед будь-яким виходом, включаючи та теги, а також будь-який пробіл.

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

— Джон Ктейджик
джерело
це не має нічого спільного з проблемою, це просто не помиляється надсиланням будь-якого іншого виводу перед заголовками
— Marnes
0

Я трохи розігрувався. 

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

працює в Firefox та Chrome станом на сьогодні. Однак я не знайшов способу змусити це працювати з завитком. Я спробував Host-Header та --resolve, не пощастило, будь-яка допомога вдячна.

Однак він працює в згортанні, якщо я його встановити

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

замість цього. (Що не працює з Firefox.)

— Міха
джерело
0

Ще одна важлива деталь, термін придатності = повинен використовувати наступний формат часу дати: Wdy, DD-Пн-РРРР HH: MM: SS GMT ( RFC6265 - Розділ 4.1.1 ).

Set-Cookie:
  name=value;
  domain=localhost;
  expires=Thu, 16-07-2019 21:25:05 GMT;
  path=/
— Траламаза
джерело
5
-1 Поточна специфікація файлів cookie - RFC 6265, tools.ietf.org/html/rfc6265 , де чітко зазначено, що дозволяється чотиризначний рік. Таким чином, погана ідея використовувати двозначні роки, які різні браузери будуть інтерпретувати по-різному.
— sleske
Правильно. Ref RFC6265 розділ 4.1.1
— Zen Cart
4
Правильно, але ще в червні 2011 року цього RFC я не знайшов. Тож ця інформація зараз невірна, коли я писав її не було.
— Траламаза
4
Не сприймайте це як незначне, все змінюється, і всі ми повинні допомогти забезпечити, щоб відповіді залишалися актуальними. Просто оновіть свою відповідь останньою інформацією, яку вам подав @sleske, і подякуйте йому за допомогу.
— Меттью Пурдон
0

Після довгих експериментів та читання різних дописів це спрацювало. Я міг встановити кілька файлів cookie, прочитати їх назад і встановити мінус часу та видалити їх.

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)
}
— Саїд
джерело
0

Єдине, що для мене працювало, - це встановити Path=/печиво.

Більше того, атрибут шляху за замовчуванням, схоже, відрізняється від браузерів до браузерів, хоча я перевірив лише два з них (Firefox та Chrome).

Chrome намагається встановити файл cookie таким, яким він є; якщо pathатрибут пропущений у Set-Cookieзаголовку, він не зберігатиметься та ігнорується.

Однак Firefox зберігає файли cookie навіть без явного pathатрибуту. Він просто встановив його запитуваним шляхом; URL-адреса мого запиту була, /api/v1/usersі шлях було встановлено /api/v1автоматично.

У будь-якому випадку, обидва браузери працювали, коли pathбуло встановлено /навіть без явного домену, тобто Domain=localhostчи чогось іншого. Отже, є деякі відмінності в тому, як кожен браузер обробляє файли cookie.

— 이준형
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.