Wysyłanie plików cookie przeglądarki podczas przekierowania 302

86

Czy są jakieś problemy z odesłaniem pliku cookie podczas przekierowania 302? Na przykład, jeśli utworzę plik cookie powrotu do adresu URL i przekieruje użytkownika w tej samej odpowiedzi, czy jakakolwiek (nowoczesna) przeglądarka zignoruje plik cookie?

http cookies http-status-code-302

— Abdullah Jibaly
źródło

Czytając trochę, myślę, że zmienne sesji byłyby lepsze niż pliki cookie, ponieważ są po stronie serwera i nie są zależne od przewidywalności klienta.

— ADTC

40

Większość przeglądarek akceptuje pliki cookie przy przekierowaniach 302. Byłem tego całkiem pewien, ale trochę poszukałem. Nie wszystkie nowoczesne przeglądarki. Link do archiwum internetowego z już usuniętego / martwego / połączenia Q / A firmy Microsoft Connect na stosie HTTP klienta Silverlight ignoruje plik cookie Set-Cookie w odpowiedziach przekierowania 302 (2010)

Myślę, że mamy teraz zamiennik IE6 i to przeglądarki Windows Mobile ...

— regilero
źródło

1

Podana strona forum nie może być dostępna przy użyciu adresu URL. Czy masz na myśli przeglądarki IE6 i Windows Mobile?

— hiroshi

1

link został przeniesiony. Ustawiłem nowy link o tej samej treści. i miałem na myśli, że specyficzne wersje IE dla urządzeń mobilnych dodają swój własny zestaw błędów

— regilero

51

Według tego posta na blogu: http://blog.dubbelboer.com/2012/11/25/302-cookie.html wszystkie główne przeglądarki, IE (6, 7, 8, 9, 10), FF (17), Safari (6.0.2), Opera (12.11) zarówno w systemie Windows, jak i Mac, ustawia pliki cookie na przekierowaniach. Dotyczy to zarówno przekierowań 301, jak i 302.

— gavenkoa
źródło

Niestety ta lista nie obejmuje Chrome, więc nie możemy dokładnie powiedzieć wszystkie popularne przeglądarki ...

— MestreLion

3

@MestreLion: w mojej przeglądarce Chrome to działa. Więc ... myślę, że możemy powiedzieć, że w końcu działa teraz, w 2019 roku.

— Michael

40

Jedna uwaga (aby uratować życie programisty):

IE i Edge ignorują Set-Cookie w odpowiedzi przekierowania, gdy domena pliku cookie to localhost .

Rozwiązanie:

Użyj 127.0.0.1 zamiast localhost .

— Michal Maťovčík
źródło

12

IE i Edge mogły to „naprawić”, więc nie ustawią również plików cookie dla 127.0.0.1. No! I zastanawiają się, dlaczego nie wszyscy programiści kochają IE ... Twoja odpowiedź wciąż kończyła się dla mnie około 4 godzinami drapania się po głowie. Dzięki!

— GlenPeterson

18

Oto błąd Chromium dotyczący tego problemu (zignorowano plik cookie Set-cookie w odpowiedzi HTTP ze stanem 302).

— llambda
źródło

1

Jeśli to prawda, to naprawdę zła wiadomość :-(

— MestreLion

Myślę, że to naprawili. Raport o błędzie nadal zawiera komunikat „WontFix”, ale w mojej przeglądarce Chrome działa.

— Michael

@Michael zauważ, że Chromium to nie Chrome: lifewire.com/chromium-and-chrome-differences-4172101 - oznacza to, że chociaż może działać w Chrome, niekoniecznie jest to prawdą w przypadku Chromium

— Thomas

3

Jest to naprawdę źle widziane podejście, ale jeśli naprawdę nie chcesz polegać na 30-krotnym zachowaniu przeglądarki z ustawionymi plikami cookie, możesz użyć meta http-equiv="refresh"„przekierowania” HTML podczas ustawiania pliku cookie. Na przykład w 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>

Serwer wyśle Set-Cookie z 200 zamiast prawidłowego przekierowania 300x, więc przeglądarka zapisze ciasteczko, a następnie wykona "przekierowanie". <a>Ogniwo jest awaryjna w przeglądarce przypadku nie wykonuje odświeżanie meta.

— MestreLion
źródło

1

Właśnie napotkałem ten problem zarówno z przeglądarką Firefox, jak i Safari, ale nie z Chrome. Z moich testów wynika, że dzieje się tak tylko wtedy, gdy domena zmienia się podczas przekierowania. Jest to typowe w przepływie OAuth2:

Dostawca identyfikatora OAuth2 (GitHub, Twitter, Google) przekierowuje przeglądarkę z powrotem do Twojej aplikacji
URL wywołania zwrotnego Twojej aplikacji weryfikuje autoryzację i ustawia pliki cookie logowania, a następnie ponownie przekierowuje do docelowego adresu URL
Docelowy adres URL wczytuje się bez ustawionych plików cookie.

Z powodów, których jeszcze nie odkryłem, niektóre pliki cookie z żądania 2 są ignorowane, a inne nie. Jeśli jednak żądanie 2 zwraca HTTP 200 z Refreshnagłówkiem (przekierowanie „meta refresh”), pliki cookie są ustawiane prawidłowo przez żądanie 3.

— Kiran Jonnalagadda
źródło

1

Podejrzewam, że przyczyną tych problemów z wywołaniem zwrotnym wrt oauth jest samesite=strict. W przypadku żądania oddzwonienia przeglądarka nadal uważa, że inicjatorem jest Google (lub którykolwiek dostawca OAuth, którego używasz). W związku z tym, jeśli ustawisz samesite = ścisłe ciasteczko w odpowiedzi 302, przeglądarka prawdopodobnie pomyśli „ah ha! To jest żądanie między witrynami przychodzące z Google do Twojej witryny” i dlatego nie wysyła pliku cookie podczas żądania przekierowanego adresu URL. Rozwiązaniem jest użycie metaodświeżania, tak jak to zrobiłeś, więc żądanie pochodzi z Twojej własnej witryny. Mógłbym gadać bzdury, ale to mój obecny pogląd.

— Ilan

1

Napotkano ten problem podczas korzystania z OpenIdConnect / IdentityServer na .Net, gdzie oddzielny interfejs API (inna nazwa hosta) obsługuje uwierzytelnianie i przekierowuje z powrotem do strony głównej.

Najpierw (do programowania na hoście lokalnym) musisz ustawić CookieSecureopcję SameAsRequestlub Neverradzić sobie z http://localhost/brakiem bezpieczeństwa. Zobacz odpowiedź Michaela Freidgeima .

Po drugie, musisz ustawić CookieSameSiteatrybut na Lax, w przeciwnym razie pliki cookie nie zostaną w ogóle zapisane. Strictnie działa tutaj!

— Willem
źródło

-1

W moim przypadku ustawiłem CookieOptions.Secure = true, ale przetestowałem to na http: // localhost ., A przeglądarka ukrywa pliki cookie zgodnie z ustawieniem.

Aby uniknąć takiego problemu, możesz ustawić opcję Cookie Secure na zgodność z protokołem Request.IsHttps, np

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

— Michael Freidgeim
źródło

2

W takim przypadku nie ustawiaj flagi bezpiecznej . Celem flagi jest poinformowanie przeglądarki, aby używała pliku cookie tylko podczas łączenia się przez HTTPS. Warunkowe ustawienie flagi zmienia nieco semantykę i tracisz plik cookie przechodząc z HTTPS -> HTTP, ale nie podczas przechodzenia z HTTP -> HTTPS. Wszystko to jest jednak ortogonalne do tego, co przeglądarki robią z Set-Cookienagłówkami w przekierowaniach 302.

— Martijn Pieters

1

Ten czas, kiedy odpowiedź -3 głosami rozwiązuje problem. Ustawiałem Secure = true, ale zapomniałem, że na hoście lokalnym używam tylko protokołu HTTP do testowania. Noob błąd. Użyj secure=request.is_securew kolbie.

— Eloff