Вопрос RFC о файлах cookie и путях

Question

Я пытаюсь установить 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 

Однако соответствующие биты РЛК я смог найти (rfc2109 и rfc2965) сказать:

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

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

...

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

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

Я неправильно понял RFC?

Заранее благодарен!

Answer 1

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

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

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

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

Answer 2

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

Если вы должны использовать Расположение заголовка (редирект), чтобы получить от «/» к «/ Foo/дом», кажется, единственный способ сделать это было бы использовать запрос string в значении заголовка Location.

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