Надсилання файлів cookie браузера під час переспрямування 302

Question 1

Чи є проблеми із відправленням файлу cookie під час переадресації 302? Наприклад, якщо я створив файл cookie з поверненням до URL-адреси та перенаправив користувача в тій самій відповіді, чи буде будь-який (сучасний) браузер ігнорувати файл cookie?

Question 2

Більшість браузерів приймають файли cookie з 302 переспрямуваннями. Я був у цьому повністю впевнений, але трохи зробив пошук. Не всі сучасні браузери. Інтернет-архів Посилання з видаленого / мертвого / microsoft connect запитання / відповідь на HTTP-стеку клієнта Silverlight ігнорує 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

Це справді з наріканням на підхід, але якщо ви дійсно хочете не покладатися на 30-кратну поведінку браузера set-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>Посилання запасний варіант у разі , якщо браузер не виконує оновлення метаданих.

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 відповідно до запиту протоколу

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