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

Question 1

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

Question 2

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

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

Question 3

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

Question 4

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

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

Решение:

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

Question 5

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

Question 6

Это действительно неодобрительный подход, но если вы действительно не хотите полагаться на поведение браузера 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>Ссылка запасной вариант в случае , если браузер не выполняет обновление метаданных.

Question 7

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

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

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

Question 8

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

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

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

Question 9

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

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

new CookieOptions()
                {
                    Path = "/",
                    HttpOnly = true,
                    Secure = Request.IsHttps,
                    Expires = expires
                }