Envío de cookies del navegador durante una redirección 302

86

¿Hay algún problema con el envío de una cookie durante un redireccionamiento 302? Por ejemplo, si creo una cookie de retorno a la URL y redirijo al usuario en la misma respuesta, ¿algún navegador (moderno) ignorará la cookie?

http cookies http-status-code-302

— Abdullah Jibaly
fuente

Leyendo un poco, creo que las variables de sesión serían mejores que las cookies, ya que son del lado del servidor y no dependen de la previsibilidad del cliente.

— ADTC

40

La mayoría de los navegadores aceptan cookies en redireccionamientos 302. Estaba bastante seguro de eso, pero hice una pequeña búsqueda. No todos los navegadores modernos . El enlace de archivo de Internet de una sesión de preguntas y respuestas de Microsoft Connect ahora eliminada / muerta / Microsoft Connect en Silverlight Client HTTP Stack ignora Set-Cookie en 302 Redirect Responses (2010)

Creo que ahora tenemos un reemplazo para IE6 y son los navegadores de Windows Mobile ...

— regilero
fuente

1

No se puede acceder a la página del foro que especificó con la URL. ¿Quiere decir que los navegadores IE6 y Windows Mobile no lo son?

— hiroshi

1

el enlace se ha movido. He establecido un nuevo enlace con el mismo contenido. y me refiero a las versiones específicas de IE para añadir móvil su propio conjunto de errores

— regilero

51

Según esta publicación de blog: http://blog.dubbelboer.com/2012/11/25/302-cookie.html todos los principales navegadores, IE (6, 7, 8, 9, 10), FF (17), Safari (6.0.2), Opera (12.11) tanto en Windows como en Mac, configuran cookies en las redirecciones. Esto es cierto para las redirecciones 301 y 302.

— Gavenkoa
fuente

Desafortunadamente, esta lista no incluye Chrome, por lo que no podemos decir exactamente todos los navegadores principales ...

— MestreLion

3

@MestreLion: en mi navegador Chrome funciona. Entonces ... creo que podemos decir que finalmente funciona ahora, en 2019.

— Michael

40

Un aviso (para salvar la vida del desarrollador):

IE y Edge ignoran Set-Cookie en la respuesta de redireccionamiento cuando el dominio de la cookie es localhost .

Solución:

Utilice 127.0.0.1 en lugar de localhost .

— Michal Maťovčík
fuente

12

IE y Edge pueden haber "arreglado" esto para que tampoco establezcan cookies para 127.0.0.1. Doh! Y se preguntan por qué no a todos los desarrolladores les encanta IE ... Tu respuesta aún terminó con unas 4 horas de rascarse la cabeza para mí. ¡Gracias!

— GlenPeterson

18

Aquí está el error de Chromium para este problema (la cookie de configuración se ignora para la respuesta HTTP con estado 302).

— llambda
fuente

1

Si esto es cierto, es realmente una mala noticia :-(

— MestreLion

Creo que lo arreglaron. El informe de error todavía dice "WontFix", pero en mi navegador Chrome funciona.

— Michael

@Michael tenga en cuenta que Chromium no es Chrome: lifewire.com/chromium-and-chrome-differences-4172101 - eso significa que si bien podría funcionar en Chrome, eso no es necesariamente cierto para Chromium

— Thomas

3

Este es un enfoque realmente desaprobado, pero si realmente no desea confiar en el comportamiento del navegador de cookies configuradas 30x, puede usar un meta http-equiv="refresh""redireccionamiento" HTML al configurar la cookie. Por ejemplo, en 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>

El servidor enviará Set-Cookie con un 200 en lugar de un redireccionamiento 300x adecuado, por lo que el navegador almacenará la cookie y luego realizará el "redireccionamiento". El <a>enlace es un respaldo en caso de que el navegador no realice la meta actualización.

— MestreLion
fuente

1

Me acabo de encontrar con este problema con Firefox y Safari, pero no con Chrome. Según mis pruebas, esto solo sucede cuando el dominio cambia durante la redirección. Esto es típico en un flujo de OAuth2:

El proveedor de identificación OAuth2 (GitHub, Twitter, Google) redirige el navegador a su aplicación
La URL de devolución de llamada de su aplicación verifica la autorización y establece cookies de inicio de sesión, luego redirige nuevamente a la URL de destino
Su URL de destino se carga sin establecer cookies.

Por razones que aún no he descubierto, algunas cookies de la solicitud 2 se ignoran y otras no. Sin embargo, si la solicitud 2 devuelve un HTTP 200 con un Refreshencabezado (la redirección de "meta actualización"), las cookies se configuran correctamente mediante la solicitud 3.

— Kiran Jonnalagadda
fuente

1

Sospecho que la razón de estos problemas de devolución de llamada de Wrt oauth es samesite=strict. Para la solicitud de devolución de llamada, el navegador todavía piensa que el creador es Google (o cualquier proveedor de oauth que use). Por lo tanto, si configura un samesite = cookie estricta en su respuesta 302, entonces el navegador probablemente piense "¡ah, ja! Esta es una solicitud entre sitios proveniente de Google a su sitio" y, por lo tanto, no envía la cookie cuando solicita la URL redirigida. La solución es usar una meta-actualización como lo hizo, por lo que su solicitud proviene de su propio sitio. Podría estar hablando tonterías, pero ese es mi pensamiento actual.

— Ilan

1

Encontré este problema mientras usaba OpenIdConnect / IdentityServer en .Net, donde una API separada (nombre de host diferente) maneja la autenticación y redirige al sitio principal.

Primero (para el desarrollo en localhost) debe establecer la CookieSecureopción SameAsRequesto Neverpara hacer frente a http://localhost/no ser seguro. Vea la respuesta de Michael Freidgeim .

En segundo lugar, debe establecer el CookieSameSiteatributo en Lax; de lo contrario, las cookies no se guardan en absoluto. Strictno funciona aqui!

— Willem
fuente

-1

En mi caso, configuré CookieOptions.Secure = true, pero lo probé en http: // localhost ., Y el navegador oculta las cookies de acuerdo con la configuración.

Para evitar este problema, puede hacer que la opción de cookies sea segura para que coincida con la solicitud del protocolo.

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

— Michael Freidgeim
fuente

2

En ese caso , no establezca la bandera de seguridad . El objetivo de la bandera es decirle al navegador que solo use la cookie cuando se conecte a través de HTTPS. La configuración condicional de la bandera cambia un poco la semántica, y pierde la cookie al pasar de HTTPS -> HTTP, pero no cuando va de HTTP -> HTTPS. Set-CookieSin embargo, todo esto es ortogonal a lo que hacen los navegadores con los encabezados en las redirecciones 302.

— Martijn Pieters

1

Ese momento en que la respuesta con -3 votos resuelve el problema. Estaba configurando Secure = true, pero olvidé que en localhost solo estoy usando http para probarlo. Error de novato. Utilizar secure=request.is_secureen matraz.

— Eloff