Как работать с доменами cookie браузера?

Ответ 1

Хотя есть RFC 2965 (Set-Cookie2, уже устарел RFC 2109), который должен определять cookie в настоящее время, большинство браузеров не полностью поддерживают это, но просто соответствуют спецификации Netscape.

Существует различие между значением атрибута Domain и эффективным доменом: первое берется из поля заголовка Set-Cookie, а второе - интерпретацией этого значения атрибута. Согласно RFC 2965, должно применяться следующее:

• Если в поле заголовка Set-Cookie нет есть атрибут домена, то эффективным доменом является домен запроса.
• Если присутствует атрибут домена, его значение будет использоваться как эффективный домен (если значение не начинается с ., оно будет добавлено клиентом).

Имея эффективный домен, он должен также domain-match текущий запрашиваемый домен для установки; иначе cookie будет пересмотрен. Это же правило применяется для выбора файлов cookie, отправляемых в запросе.

Сопоставляя эти знания на свои вопросы, следует применять следующее:

• Cookie с Domain=.example.com будет доступен для www.example.com
• Cookie с Domain=.example.com будет доступен для example.com
• Cookie с Domain=example.com будет преобразован в .example.com, и таким образом будет также доступен для www.example.com
• Cookie с Domain=example.com будет не доступен для anotherexample.com
• www.example.com будет иметь возможность устанавливать cookie для example.com
• www.example.com не сможет установить cookie для www2.example.com
• www.example.com будет не уметь устанавливать cookie для .com

И чтобы установить и прочитать файл cookie для/на www.example.com и example.com, установите его для .www.example.com и .example.com соответственно. Но первый (.www.example.com) будет доступен только для других доменов ниже этого домена (например, foo.www.example.com или bar.ww..example.com), где .example.com можно также получить в любом другом домене ниже примера .com(например, foo.example.com или bar.example.com).

Ответ 2

Предыдущие ответы немного устарели.

RFC 6265 был опубликован в 2011 году на основе консенсуса браузера в то время. С тех пор было некоторое усложнение с общедоступными доменами суффикса. Я написал статью, объясняющую текущую ситуацию - http://bayou.io/draft/cookie.domain.html

Подводя итог, правила, которые следует соблюдать в отношении домена cookie:

• Происхождение домена cookie является доменом исходного запроса.

• Если исходный домен является IP, атрибут домена cookie не должен быть установлен.

• Если атрибут домена cookie не установлен, cookie применим только к его исходному домену.

• Если установлен атрибут домена cookie,

  • cookie применим к этому домену и ко всем его поддоменам;
  • домен cookie должен быть таким же, как или родительский, домен происхождения
  • домен cookie не должен быть TLD, открытым суффиксом или родителем открытого суффикса.

Можно получить, что cookie всегда применим к его исходному домену.

В домене cookie не должно быть ведущей точки, как в .foo.com - просто используйте foo.com

В качестве примера,

• x.y.z.com может установить домен cookie для себя или родителей - x.y.z.com, y.z.com, z.com. Но не com, который является публичным суффиксом.
• cookie с доменом = y.z.com применим к y.z.com, x.y.z.com, a.x.y.z.com и т.д.

Примеры публичных суффиксов - com, edu, uk, co.uk, blogspot.com, compute.amazonaws.com

Ответ 3

Для обширного обзора покрытия содержимое RFC2965. Конечно, это не обязательно означает, что все браузеры ведут себя точно так же.

Однако правило правила для Пути по умолчанию, если ни один из указанных в cookie не является адресом в URL-адресе, из которого появился заголовок Set-Cookie. Точно так же по умолчанию для Домена указано полное имя хоста в URL-адресе, из которого прибыло Set-Cookie.

Правила сопоставления домена требуют, чтобы домен cookie соответствовал хосту, на который делается запрос. Файл cookie может указывать более широкое совпадение доменов include *. в атрибуте домена Set-Cookie (эта область, в которой браузеры могут отличаться). Согласование пути (при совпадении с доменом) является простым вопросом, что запрошенный путь должен находиться внутри пути, указанного в файле cookie. Обычно файлы cookie сеанса задаются с помощью path =/или path =/applicationName/, поэтому cookie доступен для всех запросов в приложении.

• Будет ли доступен файл cookie для .example.com для www.example.com? Да
• Будет ли файл cookie для .example.com доступен для example.com? Не знаю
• Будет ли файл cookie для example.com доступен для www.example.com? Должен не... *
• Будет ли cookie для example.com доступен для anotherexample.com? Нет
• Может ли www.example.com установить cookie для example.com? Да
• Может ли www.example.com установить cookie для www2.example.com? Нет (кроме как через .example.com)
• Может ли www.example.com установить cookie для .com? Нет (Невозможно установить cookie в этом пространстве имен, и вы не можете установить его для чего-то вроде .co.uk).

* Я не могу проверить это прямо сейчас, но у меня есть подозрение, что по крайней мере IE7/6 будет рассматривать путь example.com, как если бы он был .example.com.

Ответ 4

Последним (точнее третьим) RFC для этой проблемы является RFC-6265 (устаревшие RFC-2965, которые, в свою очередь, устаревшие RFC-2109).

В соответствии с этим, если сервер пропускает атрибут "Домен", пользовательский агент будет возвращать cookie только на исходный сервер (сервер, на котором находится данный ресурс). Но также предупреждает, что некоторые существующие пользовательские агенты обрабатывают отсутствующий атрибут Domain так, как если бы атрибут Domain присутствовал и содержал текущее имя хоста (например, если example.com возвращает заголовок Set-Cookie без домена атрибуты, эти пользовательские агенты также будут по ошибке отправлять куки на www.example.com).

Если указан атрибут "Домен", он будет считаться полным доменным именем (если в атрибуте есть начальная точка, он будет игнорироваться). Сервер должен соответствовать домену, указанному в атрибуте (иметь точно такое же имя домена или быть его поддоменом), чтобы получить этот файл cookie. Точнее это указано здесь.

Так, например:

• атрибут cookie Domain=.example.com эквивалентен Domain=example.com
• файлы cookie с такими атрибутами домена будут доступны для example.com и www.example.com
• .файлы cookie с такими атрибутами домена будут недоступны для другого сайта-примера
• указание атрибута cookie, например Domain=www.example.com, закроет путь для www4.example.com

PS: запятая в атрибуте Domain заставит пользовательский агент игнорировать атрибут = (

Ответ 5

RFC, как известно, не отражают реальность.

Лучше проверить draft-ietf-httpstate-cookie, работа выполняется.

Ответ 6

Существуют правила, определяющие, будет ли браузер принимать заголовок ответа заголовка Set-заголовка (написание на стороне сервера cookie), несколько разные правила/интерпретации для набора cookie с использованием Javascript (я не тестировал VBScript).

Затем существуют правила, определяющие, будет ли браузер отправлять cookie вместе с запросом страницы.

Существуют различия между основными браузерами, как обрабатываются совпадения доменов, и как интерпретируются параметры в значениях пути. Вы можете найти некоторые эмпирические данные в статье Как разные браузеры обрабатывают файлы cookie по-разному

Ответ 7

Я протестировал все случаи в последних версиях Chrome, Firefox, Safari в 2019 году.

Ответ на Добавлено:

• Будет ли файл cookie для .example.com доступен для www.example.com? ДА
• Будет ли файл cookie для .example.com доступен для example.com? ДА
• Будет ли файл cookie для example.com доступен для www.example.com? НЕТ, домен без подстановочных знаков совпадает только сам по себе.
• Будет ли файл cookie для example.com доступен для anotherexample.com? НЕТ
• Сможет ли www.example.com установить cookie для example.com? НЕТ, он сможет установить cookie для ".example.com", но не "example.com".
• Сможет ли www.example.com установить cookie для www2.example.com? НЕТ. Но он может установить cookie для .example.com, к которому имеет доступ www2.example.com.
• Сможет ли www.example.com установить cookie для .com? НЕТ

Ответ 8

Я с удивлением прочитал раздел 3.3.2 об отказе от куки файлов:

http://tools.ietf.org/html/rfc2965

Это говорит о том, что браузер должен отклонить файл cookie с сайта x.y.z.com с доменом .z.com, потому что "x.y" содержит точку. Итак, если я не неправильно интерпретирую RFC и/или вопросы выше, могут быть добавлены вопросы:

Будет ли доступен файл cookie для .example.com для www.yyy.example.com? Нет.

Будет ли файл cookie, установленный сервером происхождения www.yyy.example.com, с доменом .example.com, имеет ли значение, отправленное агентом пользователя, на xxx.example.com? Нет.

Ответ 9

Будет ли www.example.com установить cookie для .com?

Нет, но example.com.fr может установить cookie для example2.com.fr. Firefox защищает от этого, поддерживая список TLD: http://securitylabs.websense.com/content/Blogs/3108.aspx

Очевидно, что Internet Explorer не разрешает двухбуквенным доменам устанавливать файлы cookie, что, я полагаю, объясняет, почему o2.ie просто перенаправляется на o2online.ie. Я часто задавался этим вопросом.