Определен ли порт файлов cookie HTTP?

У меня есть две HTTP-службы, работающие на одной машине. Я просто хочу знать, разделяют ли они свои куки или браузер различает два серверных сокета.

Текущей спецификацией cookie является RFC 6265 , которая заменяет RFC 2109 и RFC 2965 (оба RFC теперь помечены как «Исторические») и формализует синтаксис для использования файлов cookie в реальном мире. В нем четко говорится:

1. Введение

...

По историческим причинам куки-файлы содержат ряд нарушений безопасности и конфиденциальности. Например, сервер может указать, что данный файл cookie предназначен для «безопасных» соединений, но атрибут Secure не обеспечивает целостность в присутствии активного сетевого злоумышленника. Точно так же файлы cookie для данного хоста совместно используются всеми портами на этом хосте, хотя обычная «политика одного и того же источника», используемая веб-браузерами, изолирует контент, извлекаемый через разные порты.

А также:

8,5. Слабая конфиденциальность

Файлы cookie не обеспечивают изоляцию по порту . Если файл cookie доступен для чтения службой, работающей на одном порту, файл cookie также может быть прочитан службой, работающей на другом порту того же сервера. Если файл cookie доступен для записи службой на одном порту, файл cookie также доступен для записи службой, работающей на другом порту того же сервера. По этой причине серверам НЕ СЛЕДУЕТ запускать службы, не доверяющие друг другу, на разных портах одного и того же хоста и использовать файлы cookie для хранения конфиденциальной информации.

В соответствии с RFC2965 3.3.1 (за которым могут или не могут следовать браузеры), если порт явно не указан в portпараметре Set-Cookieзаголовка, куки могут отправляться или не отправляться на любой порт.

В Руководстве по безопасности браузера Google говорится: по умолчанию область действия cookie ограничивается всеми URL-адресами текущего имени хоста и не привязана к информации о порте или протоколе. и несколько строк позже. Нет возможности ограничить файлы cookie только одним DNS-именем, [...] аналогично, нет способа ограничить их определенным портом. (Кроме того , имейте в виду, что IE делает число не фактор порта в его же происхождения политики вообще .)

Так что, похоже, здесь нельзя полагаться на какое-либо четко определенное поведение.

Это действительно старый вопрос, но я решил добавить обходной путь, который использовал.

У меня на ноутбуке работают две службы (одна на порту 3000, а другая на 4000). Когда я переключался между ( http://localhost:3000и http://localhost:4000), Chrome передавал один и тот же cookie, каждый сервис не понимал cookie и генерировал новый.

Я обнаружил, что если я получу доступ http://localhost:3000и http://127.0.0.1:4000, проблема исчезнет, ​​так как Chrome сохранит cookie для localhost и один для 127.0.0.1.

Опять же, никто не может заботиться об этом, но это было легко и полезно для моей ситуации.

Это большая серая область в SOP cookie (Политика одинакового происхождения).

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

Лучший подход состоит в том, чтобы получить 2 доменных имени для одного и того же IP и не полагаться на номера портов для файлов cookie.

Альтернативный способ обойти проблему - сделать так, чтобы имя файла cookie сеанса было связано с портом. Например:

• mysession8080 для сервера, работающего на порте 8080
• mysession8000 для сервера, работающего на порту 8000

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

Имейте в виду, что ваше приложение получит оба куки, и вам нужно запросить тот, который соответствует вашему порту.

Нет необходимости указывать точный номер порта в имени файла cookie, но это более удобно.

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

В IE 8 файлы cookie (проверяются только на локальном хосте) распределяются между портами. В FF 10 их нет.

Я опубликовал этот ответ, чтобы у читателей был хотя бы один конкретный вариант для тестирования каждого сценария.

У меня была похожая проблема при запуске (и попытке отладки) двух разных приложений Django на одной машине.

Я запускал их с этими командами:

./manage.py runserver 8000
./manage.py runserver 8001

Когда я входил в первый, а затем во второй, я всегда выходил из первого и наоборот.

Я добавил это в мой / etc / hosts

127.0.0.1    app1
127.0.0.1    app2

Затем я запустил два приложения с помощью этих команд:

./manage.py runserver app1:8000
./manage.py runserver app2:8001

Задача решена :)

Это необязательно.

Порт может быть указан, поэтому куки могут быть привязаны к конкретному порту. Это не обязательно, веб-сервер / приложение должно заботиться об этом.

Источник: статья в немецкой Википедии , RFC2109 , глава 4.3.1.