RFC вопрос о файлах cookie и путях - PullRequest
3 голосов
/ 26 января 2010

Я пытаюсь установить cookie сеанса, ограниченные определенным путем (скажем, /foo), когда пользователь входит в систему. Сложность состоит в том, что страница входа в систему находится на /, но запрос немедленно перенаправляет на /foo/something. Примерно так:

Запрос:

POST / HTTP/1.1

username=foo&password=bar

Ответ:

HTTP/1.0 302 Found
Location: http://example.com/foo/home
Set-Cookie: session=whatever; path=/foo

Однако соответствующие биты RFC, которые я смог найти ( rfc2109 и rfc2965 ), говорят следующее:

Для предотвращения возможных нарушений безопасности или конфиденциальности, пользовательский агент отклоняет файл cookie (не сохраняет его информацию), если какой-либо из верно следующее:

  • Значение атрибута Path не является префиксом запроса. URI.

...

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

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

Я неправильно читаю RFC?

Заранее спасибо!

Ответы [ 2 ]

1 голос
/ 30 апреля 2010

Не обращайте внимания на эти RFC; они очень сильно расходятся с реальностью.

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

См: http://datatracker.ietf.org/doc/draft-ietf-httpstate-cookie/

Если вы не найдете в проекте текста, касающегося вашего вопроса, сообщите об этом в Рабочую группу!

0 голосов
/ 27 января 2010

Исходя из вашего вопроса, я думаю, что вы понимаете RFC правильно. Похоже, вы хотите установить cookie после перенаправления на '/ foo / home' . Я думаю, что реальный вопрос заключается в следующем: «Как вы скажете '/ foo / home' , что пользователь был аутентифицирован правильно '/' ? "

Если вы должны использовать заголовок Location (перенаправление), чтобы получить от '/' до '/ foo / home' Похоже, что единственный способ сделать это - использовать параметр строки запроса в значении заголовка Location.

Может быть, стоит рассмотреть вопрос о дизайне: почему пользователи аутентифицируются по URL-адресу вне пути, по которому они будут получать безопасный доступ? Если единственный защищенный контент находится под '/ foo' , то почему бы не POST к '/ foo / login' вместо '/' для аутентификации?

...