Отправка файлов 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
                }

Answer 1

87

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

http cookies http-status-code-302 Абдулла Джибали
источник

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

ADTC

Answer 2

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

ADTC

Answer 3

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

Answer 4

1

Указанная вами страница форума не может быть доступна по URL-адресу. Вы имеете в виду, что браузеры IE6 и Windows Mobile - нет?

hiroshi

Answer 5

1

ссылка переехала. Я установил новую ссылку с таким же содержанием. и я имел в виду конкретные версии IE для мобильных устройств, добавляющие собственный набор ошибок

regilero

Answer 6

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 он работает. Итак .. Я думаю, мы можем сказать, что это наконец-то

Майкл

Answer 7

К сожалению, в этот список не входит Chrome, поэтому мы не можем точно сказать, все основные браузеры ...

MestreLion

Answer 8

3

@MestreLion: в моем браузере Chrome он работает. Итак .. Я думаю, мы можем сказать, что это наконец-то

Майкл

Answer 9

41

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

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

Решение:

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

Михал Мановчик
источник

12

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

GlenPeterson

Answer 10

12

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

GlenPeterson

Answer 11

18

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

лямбда
источник

1

Если это правда, то это действительно плохие новости :-(

MestreLion

Думаю, исправили. В отчете об ошибке по-прежнему написано «WontFix», но в моем браузере Chrome он работает.

Майкл

@Michael, обратите внимание, что Chromium - это не Chrome: lifewire.com/chromium-and-chrome-differences-4172101 - это означает, что, хотя он может работать в Chrome, это не обязательно верно для Chromium

Томас

Answer 12

1

Если это правда, то это действительно плохие новости :-(

MestreLion

Answer 13

Думаю, исправили. В отчете об ошибке по-прежнему написано «WontFix», но в моем браузере Chrome он работает.

Майкл

Answer 14

@Michael, обратите внимание, что Chromium - это не Chrome: lifewire.com/chromium-and-chrome-differences-4172101 - это означает, что, хотя он может работать в Chrome, это не обязательно верно для Chromium

Томас

Answer 15

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

Answer 16

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

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

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

Answer 17

1

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

Илан

Answer 18

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

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

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

Answer 19

-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

Answer 20

2

В этом случае не устанавливайте безопасный флаг . Весь смысл флага - указать браузеру использовать cookie только при подключении по HTTPS. Условная установка флага несколько изменяет семантику, и вы теряете cookie при переходе с HTTPS на HTTP, но не при переходе с HTTP на HTTPS. Однако все это ортогонально тому, что браузеры делают с Set-Cookieзаголовками на 302 редиректах.

Мартейн Питерс

Answer 21

1

Тот раз, когда ответ с -3 голосами решает проблему. Я устанавливал Secure = true, но забыл, что на localhost я просто использую http для его проверки. Ошибка нубов. Использовать secure=request.is_secureв колбе.

Eloff

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

Ответы: