Ответы:
Текущей спецификацией cookie является RFC 6265 , которая заменяет RFC 2109 и RFC 2965 (оба RFC теперь помечены как «Исторические») и формализует синтаксис для использования файлов cookie в реальном мире. В нем четко говорится:
- Введение
...
По историческим причинам куки-файлы содержат ряд нарушений безопасности и конфиденциальности. Например, сервер может указать, что данный файл 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.
Опять же, никто не может заботиться об этом, но это было легко и полезно для моей ситуации.
localhostне может использоваться совместно 127.0.0.1и наоборот. Но куки-файлы на одном хосте / домене, независимо от порта, являются разделяемыми.
Это большая серая область в SOP cookie (Политика одинакового происхождения).
Теоретически, вы можете указать номер порта в домене, и куки не будут разделены. На практике это не работает с несколькими браузерами, и вы столкнетесь с другими проблемами. Так что это возможно только в том случае, если ваши сайты не предназначены для широкой публики, и вы можете контролировать, какие браузеры использовать.
Лучший подход состоит в том, чтобы получить 2 доменных имени для одного и того же IP и не полагаться на номера портов для файлов cookie.
Альтернативный способ обойти проблему - сделать так, чтобы имя файла cookie сеанса было связано с портом. Например:
Ваш код может получить доступ к конфигурации веб-сервера, чтобы выяснить, какой порт использует ваш сервер, и соответствующим образом назвать cookie.
Имейте в виду, что ваше приложение получит оба куки, и вам нужно запросить тот, который соответствует вашему порту.
Нет необходимости указывать точный номер порта в имени файла cookie, но это более удобно.
Как правило, имя файла cookie может кодировать любой другой параметр, специфичный для используемого вами экземпляра сервера, поэтому его можно декодировать в правильном контексте.
У меня была похожая проблема при запуске (и попытке отладки) двух разных приложений 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
Задача решена :)
127.0.0.1:8000для одного, localhost:8000для секунды, и, возможно ::1:8000(возможно [::1]:8080) для третьего, даже не трогая файл hosts.
::1 app1 app2 app3 app4 app5 appN
Это необязательно.
Порт может быть указан, поэтому куки могут быть привязаны к конкретному порту. Это не обязательно, веб-сервер / приложение должно заботиться об этом.
Источник: статья в немецкой Википедии , RFC2109 , глава 4.3.1.
Portпараметр вSet-Cookieзаголовке (потому что практически никто не использовал его на практике) и очень четко указывает, что файлы cookie на одном хосте больше НЕ различимы по портам.