Отправка файлов cookie браузера во время переадресации 302

Есть ли проблемы с отправкой файла cookie во время перенаправления 302? Например, если я создам файл cookie с возвратом к URL-адресу и перенаправлю пользователя в том же ответе, будет ли любой (современный) браузер игнорировать файл cookie?


http cookies http-status-code-302
person Abdullah Jibaly    schedule 14.01.2011    source источник
comment
Читая немного, я думаю, что переменные сеанса были бы лучше, чем файлы cookie, поскольку они находятся на стороне сервера и не зависят от предсказуемости клиента.   -  person ADTC    schedule 27.11.2016

Ответы (8)


arrow_upward
41
arrow_downward

Большинство браузеров принимают файлы cookie при переадресации 302. Я был в этом совершенно уверен, но немного поискал. Не все современные браузеры. Интернет-архив Ссылка из уже удаленного/мертвого/ microsoft connect Вопросы и ответы по HTTP-стеку клиента Silverlight игнорирует Set-Cookie on 302 ответа с переадресацией (2010 г.)

Я думаю, теперь у нас есть замена IE6 и браузеры Windows Mobile...

person regilero    schedule 14.01.2011
comment
Указанная вами страница форума не может быть доступна по указанному URL. Вы имеете в виду, что браузеры IE6 и Windows Mobile не являются таковыми? - person hiroshi; 12.02.2013
comment
ссылка переехала. Я установил новую ссылку с таким же содержанием. и я имел в виду, что версии IE для мобильных устройств добавляют свой собственный набор ошибок - person regilero; 13.02.2013

arrow_upward
55
arrow_downward

Согласно этому сообщению в блоге: http://blog.dubbelboer.com/2012/11/25/302-cookie.html все основные браузеры, IE (6, 7, 8, 9, 10), FF (17), Safari (6.0.2), Opera (12.11) оба на Windows и Mac, установите файлы cookie при перенаправлении. Это верно как для 301, так и для 302 редиректов.

Как отметил @Benni:

https://www.chromium.org/administrators/policy-list-3/cookie-legacy-samesite-policies

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

  • Файл cookie с "SameSite=Strict" будет отправлен только с запросом того же сайта.
  • Файл cookie с "SameSite=Lax" будет отправлен с запросом на тот же сайт или с навигацией на верхнем уровне между сайтами с помощью безопасного метода HTTP.
  • Файл cookie с "SameSite=None" будет отправлен как с запросами на одном сайте, так и с запросами между сайтами.
person gavenkoa    schedule 13.11.2013
comment
К сожалению, этот список не включает Chrome, поэтому мы не можем точно сказать все основные браузеры... - person MestreLion; 30.07.2019
comment
@MestreLion: в моем браузере Chrome это работает. Итак.. Я думаю, мы можем сказать, что это, наконец, работает сейчас, в 2019 году. - person Michael; 11.08.2019
comment
Это зависит от той же политики сайта: со strict это все равно не работает. - person Benni; 25.11.2020

arrow_upward
45
arrow_downward

Одно уведомление (для спасения жизни разработчика):

IE и Edge игнорируют Set-Cookie в ответе перенаправления, когда доменом файла cookie является localhost.

Решение:

Используйте 127.0.0.1 вместо localhost.

person Michal Maťovčík    schedule 28.10.2016
comment
IE и Edge, возможно, исправили это, поэтому они также не будут устанавливать файлы cookie для 127.0.0.1. Дох! И они удивляются, почему разработчики не все любят IE... Ваш ответ все же закончился для меня часами 4-х головоломок. Спасибо! - person GlenPeterson; 16.03.2017

arrow_upward
20
arrow_downward

здесь ошибка Chromium для этой проблемы (Set-cookie игнорируется для ответа HTTP со статусом 302).

person lammy    schedule 16.06.2016
comment
Если это правда, то это действительно плохие новости :-( - person MestreLion; 30.07.2019
comment
Я думаю, они исправили это. В отчете об ошибке по-прежнему написано WontFix, но в моем браузере Chrome это работает. - person Michael; 11.08.2019
comment
@Michael обратите внимание, что Chromium — это не Chrome: lifewire.com/chromium-and-chrome -differences-4172101 — это означает, что, хотя это может работать в Chrome, это не обязательно верно для Chromium. - person Thomas; 30.08.2019

arrow_upward
6
arrow_downward

Это действительно неодобрительный подход, но если вы действительно не хотите полагаться на поведение браузера с 30-кратным набором файлов cookie, вы можете использовать HTML meta http-equiv="refresh" «перенаправление» при установке файла cookie. Например, в PHP:

<?php
    ...
    setcookie("cookie", "value", ...);
    url="page.php";
?>
<html>
<head><meta http-equiv="refresh" content=1;url="<?=$url?>"></head>
<body><a href="<?=$url?>">Continue...</a></body>
</html>

Сервер отправит Set-Cookie с перенаправлением 200 вместо правильного перенаправления 300x, поэтому браузер сохранит файл cookie, а затем выполнит «перенаправление». Ссылка <a> является резервной на случай, если браузер не выполняет метаобновление.

person MestreLion    schedule 30.07.2019

arrow_upward
5
arrow_downward

Я только что столкнулся с этой проблемой как с Firefox, так и с Safari, но не с Chrome. Из моего тестирования это происходит только тогда, когда домен меняется во время перенаправления. Это типично для потока OAuth2:

  1. Поставщик идентификатора OAuth2 (GitHub, Twitter, Google) перенаправляет браузер обратно в ваше приложение.
  2. URL-адрес обратного вызова вашего приложения проверяет авторизацию и устанавливает файлы cookie для входа, а затем снова перенаправляет на целевой URL-адрес.
  3. Ваш целевой URL загружается без каких-либо файлов cookie.

По причинам, которые я еще не выяснил, некоторые файлы cookie из запроса 2 игнорируются, а другие нет. Однако, если запрос 2 возвращает HTTP 200 с заголовком Refresh (перенаправление метаобновления), файлы cookie устанавливаются правильно запросом 3.

person Kiran Jonnalagadda    schedule 07.08.2020
comment
Я подозреваю, что причиной этих проблем с обратным вызовом oauth является samesite=strict. Для запроса обратного вызова браузер по-прежнему считает, что отправителем является Google (или любой другой провайдер oauth, который вы используете). Следовательно, если вы установите файл cookie samesite=strict в своем ответе 302, браузер, вероятно, подумает: ах-ха! это межсайтовый запрос, поступающий от Google на ваш сайт, и, следовательно, не отправляет файл cookie при запросе перенаправленного URL-адреса. Исправление состоит в том, чтобы использовать мета-обновление, как вы это сделали, чтобы ваш запрос исходил с вашего собственного сайта. Я мог бы говорить чушь, но это мое текущее мышление. - person Ilan; 20.09.2020

arrow_upward
4
arrow_downward

Столкнулся с этой проблемой при использовании OpenIdConnect/IdentityServer в .Net, где отдельный API (другое имя хоста) обрабатывает аутентификацию и перенаправляет обратно на основной сайт.

Сначала (для разработки на локальном хосте) вам нужно установить для параметра CookieSecure значение SameAsRequest или Never, чтобы иметь дело с http://localhost/ небезопасным. См. ответ Майкла Фрейдгейма.

Во-вторых, вам нужно установить для атрибута CookieSameSite значение Lax, иначе файлы cookie вообще не будут сохраняться. Strict здесь не работает!

person Willem    schedule 01.09.2020
comment
Чтобы немного уточнить - файлы cookie сохраняются. Они просто не отправляются на следующий запрос, поэтому похоже, что они не сохраняются. - person jjnguy; 06.03.2021

arrow_upward
-1
arrow_downward

В моем случае я установил CookieOptions.Secure=true, но протестировано на http://localhost, и браузер скрывает файлы cookie в соответствии с настройка.

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

new CookieOptions()
                {
                    Path = "/",
                    HttpOnly = true,
                    Secure = Request.IsHttps,
                    Expires = expires
                }
person Michael Freidgeim    schedule 02.10.2017
comment
В этом случае не устанавливайте флаг безопасности. Весь смысл флага в том, чтобы указать браузеру использовать cookie только при подключении через HTTPS. Условная установка флага несколько меняет семантику, и вы теряете cookie при переходе с HTTPS -> HTTP, но не при переходе с HTTP -> HTTPS. Однако все это ортогонально тому, что браузеры делают с заголовками Set-Cookie при переадресации 302. - person Martijn Pieters; 26.01.2019
comment
В тот раз, когда ответ с -3 голосами решит проблему. Я устанавливал Secure=true, но забыл, что на локальном хосте я просто использую http для проверки. Нубская ошибка. Используйте secure=request.is_secure в колбе. - person Eloff; 22.05.2020