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

87

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

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

Ответы:

41

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

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

Regilero
источник
1
Указанная вами страница форума не может быть доступна по URL-адресу. Вы имеете в виду, что браузеры IE6 и Windows Mobile - нет?
hiroshi
1
ссылка переехала. Я установил новую ссылку с таким же содержанием. и я имел в виду конкретные версии IE для мобильных устройств, добавляющие собственный набор ошибок
regilero
52

Согласно этому сообщению в блоге: 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 редиректов.

гавенкоа
источник
К сожалению, в этот список не входит Chrome, поэтому мы не можем точно сказать, все основные браузеры ...
MestreLion
3
@MestreLion: в моем браузере Chrome он работает. Итак .. Я думаю, мы можем сказать, что это наконец-то
Майкл
41

Одно замечание (чтобы спасти жизнь разработчика):

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

Решение:

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

Михал Мановчик
источник
12
IE и Edge, возможно, «исправили» это, поэтому они также не будут устанавливать файлы cookie для 127.0.0.1. Дох! И они удивляются, почему не все разработчики любят IE ... Ваш ответ все же закончился для меня 4 часами головокружения. Благодарность!
GlenPeterson
18

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

лямбда
источник
1
Если это правда, то это действительно плохие новости :-(
MestreLion
Думаю, исправили. В отчете об ошибке по-прежнему написано «WontFix», но в моем браузере Chrome он работает.
Майкл
@Michael, обратите внимание, что Chromium - это не Chrome: lifewire.com/chromium-and-chrome-differences-4172101 - это означает, что, хотя он может работать в Chrome, это не обязательно верно для Chromium
Томас
3

Это действительно неодобрительный подход, но если вы действительно не хотите полагаться на поведение браузера 30x set-cookie, вы можете использовать meta http-equiv="refresh"«перенаправление» HTML при установке 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>Ссылка запасной вариант в случае , если браузер не выполняет обновление метаданных.

MestreLion
источник
1

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

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

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

Киран Йонналагадда
источник
1
Я подозреваю, что причина проблем с обратным вызовом oauth в samesite=strict. Для запроса обратного вызова браузер по-прежнему считает, что отправителем является Google (или любой другой поставщик oauth, который вы используете). Следовательно, если вы установите samesite = strict cookie в своем ответе 302, тогда браузер, вероятно, подумает: «Ага! Это межсайтовый запрос, поступающий от Google на ваш сайт», и, следовательно, не отправляет cookie при запросе перенаправленного URL-адреса. Исправление состоит в том, чтобы использовать мета-обновление, как вы это сделали, поэтому ваш запрос поступает с вашего собственного сайта. Я мог бы говорить чушь, но сейчас я так думаю.
Илан
1

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

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

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

Виллем
источник
-1

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

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

new CookieOptions()
                {
                    Path = "/",
                    HttpOnly = true,
                    Secure = Request.IsHttps,
                    Expires = expires
                }
Майкл Фрейджейм
источник
2
В этом случае не устанавливайте безопасный флаг . Весь смысл флага - указать браузеру использовать cookie только при подключении по HTTPS. Условная установка флага несколько изменяет семантику, и вы теряете cookie при переходе с HTTPS на HTTP, но не при переходе с HTTP на HTTPS. Однако все это ортогонально тому, что браузеры делают с Set-Cookieзаголовками на 302 редиректах.
Мартейн Питерс
1
Тот раз, когда ответ с -3 голосами решает проблему. Я устанавливал Secure = true, но забыл, что на localhost я просто использую http для его проверки. Ошибка нубов. Использовать secure=request.is_secureв колбе.
Eloff