Envio de cookies do navegador durante um redirecionamento 302

86

Há algum problema com o envio de um cookie durante um redirecionamento 302? Por exemplo, se eu criar um cookie de retorno ao url e redirecionar o usuário na mesma resposta, algum navegador (moderno) ignorará o cookie?

http cookies http-status-code-302

— Abdullah Jibaly
fonte

Lendo um pouco, estou pensando que as variáveis de sessão seriam melhores do que os cookies, uma vez que são do lado do servidor e não dependem da previsibilidade do cliente.

— ADTC

40

A maioria dos navegadores está aceitando cookies em redirecionamentos 302. Eu tinha certeza disso, mas fiz uma pequena pesquisa. Nem todos os navegadores modernos . Link de arquivo da Internet de uma Q / A agora removida / morta / microsoft connect na pilha HTTP do cliente Silverlight ignora Set-Cookie em 302 Redirect Respostas (2010)

Acho que agora temos um substituto para o IE6 e seus navegadores Windows Mobile ...

— regilero
fonte

1

A página do fórum que você especificou não pode ser acessada com o URL. Você quer dizer que os navegadores IE6 e Windows Mobile não são?

— hiroshi

1

o link mudou. Eu defini um novo link com praticamente o mesmo conteúdo. e eu quis dizer que as versões específicas do IE para celular adicionam seu próprio conjunto de bugs

— regilero

51

De acordo com esta postagem do blog: http://blog.dubbelboer.com/2012/11/25/302-cookie.html todos os principais navegadores, IE (6, 7, 8, 9, 10), FF (17), Safari (6.0.2), Opera (12.11) no Windows e Mac, define cookies nos redirecionamentos. Isso é verdadeiro para os redirecionamentos 301 e 302.

— Gavenkoa
fonte

Infelizmente esta lista não inclui o Chrome, então não podemos dizer exatamente todos os principais navegadores ...

— MestreLion

3

@MestreLion: no meu navegador Chrome funciona. Então ... acho que podemos dizer que finalmente funciona agora, em 2019.

— Michael

40

Um aviso (para salvar a vida do desenvolvedor):

IE e Edge estão ignorando Set-Cookie na resposta de redirecionamento quando o domínio do cookie é localhost .

Solução:

Use 127.0.0.1 em vez de localhost .

— Michal Maťovčík
fonte

12

O IE e o Edge podem ter "consertado" isso para que também não definam cookies para 127.0.0.1. Doh! E eles se perguntam por que os desenvolvedores não amam o IE ... Sua resposta ainda terminou com cerca de 4 horas de coçar a cabeça para mim. Obrigado!

— GlenPeterson

18

Aqui está o bug do Chromium para esse problema (Set-cookie ignorado para resposta HTTP com status 302).

— llambda
fonte

1

Se isso for verdade, são realmente más notícias :-(

— MestreLion

Eu acho que eles consertaram. O relatório de bug ainda diz "WontFix", mas no meu navegador Chrome funciona.

— Michael

@Michael observe que o Chromium não é o Chrome: lifewire.com/chromium-and-chrome-differences-4172101 - isso significa que, embora possa funcionar no Chrome, isso não é necessariamente verdadeiro para o Chromium

— Thomas

3

Esta é uma abordagem realmente desaprovada, mas se você realmente deseja não confiar no comportamento do navegador 30x set-cookie, você pode usar um meta http-equiv="refresh""redirecionamento" de HTML ao configurar o cookie. Por exemplo, em 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>

O servidor enviará Set-Cookie com um 200 em vez de um redirecionamento 300x adequado, de modo que o navegador armazenará o cookie e executará o "redirecionamento". O <a>link é um substituto caso o navegador não execute a atualização meta.

— MestreLion
fonte

1

Acabei de ter esse problema com o Firefox e o Safari, mas não com o Chrome. Pelo meu teste, isso só acontece quando o domínio muda durante o redirecionamento. Isso é típico em um fluxo OAuth2:

O provedor de id OAuth2 (GitHub, Twitter, Google) redireciona o navegador de volta para seu aplicativo
O URL de retorno de chamada do seu aplicativo verifica a autorização e define os cookies de login e, em seguida, redireciona novamente para o URL de destino
Seu URL de destino carrega sem nenhum conjunto de cookies.

Por motivos que ainda não descobri, alguns cookies da solicitação 2 são ignorados, enquanto outros não. No entanto, se a solicitação 2 retornar um HTTP 200 com um Refreshcabeçalho (o redirecionamento de "atualização meta"), os cookies serão configurados corretamente pela solicitação 3.

— Kiran Jonnalagadda
fonte

1

Eu suspeito que o motivo para esses problemas de callback wrt oauth é samesite=strict. Para a solicitação de retorno de chamada, o navegador ainda pensa que o originador é o Google (ou qualquer provedor oauth que você usa). Portanto, se você definir um cookie samesite = strict em sua resposta 302, o navegador provavelmente pensará "ah ha! Esta é uma solicitação de cross-site proveniente do Google para o seu site" e, portanto, não envia o cookie ao solicitar o url redirecionado. A correção é usar uma meta-atualização conforme você fez, de modo que sua solicitação venha do seu próprio site. Eu poderia estar falando merda, mas esse é o meu pensamento atual.

— Ilan,

1

Esse problema foi encontrado ao usar OpenIdConnect / IdentityServer no .Net, onde uma API separada (nome de host diferente) lida com a autenticação e redireciona de volta para o site principal.

Primeiro (para desenvolvimento em localhost) você precisa definir a CookieSecureopção de SameAsRequestou Neverpara lidar com a http://localhost/falta de segurança. Veja a resposta de Michael Freidgeim .

Em segundo lugar, você precisa definir o CookieSameSiteatributo para Lax, caso contrário, os cookies não serão salvos. Strictnão funciona aqui!

— Willem
fonte

-1

No meu caso, configurei CookieOptions.Secure = true, mas testei em http: // localhost ., E o navegador escondeu os cookies de acordo com a configuração.

Para evitar esse problema, você pode tornar a opção segura do cookie para corresponder ao protocolo Request.IsHttps, por exemplo

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

— Michael Freidgeim
fonte

2

Nesse caso , não defina o sinalizador seguro . O objetivo do sinalizador é dizer ao navegador para usar apenas o cookie ao conectar-se por HTTPS. Definir condicionalmente o sinalizador altera um pouco a semântica, e você perde a transição do cookie de HTTPS -> HTTP, mas não ao ir de HTTP -> HTTPS. Set-CookiePorém, tudo isso é ortogonal ao que os navegadores fazem com os cabeçalhos em redirecionamentos 302.

— Martijn Pieters

1

Aquele momento em que a resposta com -3 votos resolve o problema. Estava definindo Secure = true, mas esqueci que no localhost estou apenas usando http para testar. Erro de Noob. Use secure=request.is_secureem frasco.

— Eloff