Ci sono problemi con la restituzione di un cookie durante un reindirizzamento 302? Ad esempio, se creo un cookie di ritorno all'URL e reindirizzo l'utente nella stessa risposta, un browser (moderno) ignorerà il cookie?
Risposte:
La maggior parte dei browser accetta i cookie sui reindirizzamenti 302. Ne ero abbastanza sicuro, ma ho fatto una piccola ricerca. Non tutti i browser moderni . Il collegamento all'archivio Internet da una domanda / risposta ora rimossa / morta / microsoft connect sullo stack HTTP del client Silverlight ignora Set-Cookie sulle risposte di reindirizzamento 302 (2010)
Penso che ora abbiamo un sostituto per IE6 e sono i browser Windows Mobile ...
Secondo questo post del blog: http://blog.dubbelboer.com/2012/11/25/302-cookie.html tutti i principali browser, IE (6, 7, 8, 9, 10), FF (17), Safari (6.0.2), Opera (12.11) sia su Windows che su Mac, impostano i cookie sui reindirizzamenti. Questo è vero per i reindirizzamenti 301 e 302.
Come ha notato @Benni:
https://www.chromium.org/administrators/policy-list-3/cookie-legacy-samesite-policies
L'attributo SameSite di un cookie specifica se il cookie deve essere limitato a un contesto proprietario o dello stesso sito. Sono consentiti diversi valori di SameSite:
- Un cookie con
"SameSite=Strict"verrà inviato solo con una richiesta dallo stesso sito.- Un cookie con
"SameSite=Lax"verrà inviato con una richiesta dello stesso sito o una navigazione di primo livello tra siti con un metodo HTTP "sicuro"."SameSite=None"Verrà inviato un cookie con richieste sia per lo stesso sito che per più siti.
Un avviso (per salvare la vita dello sviluppatore):
IE e Edge ignorano Set-Cookie nella risposta di reindirizzamento quando il dominio del cookie è localhost .
Soluzione:
Usa 127.0.0.1 invece di localhost .
Ecco il bug di Chromium per questo problema (set-cookie ignorato per la risposta HTTP con stato 302).
Questo è un approccio davvero disapprovato, ma se davvero non vuoi fare affidamento sul comportamento del browser con set di cookie 30x potresti usare un meta http-equiv="refresh""reindirizzamento" HTML durante l'impostazione del cookie. Ad esempio, in 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>
Il server invierà Set-Cookie con un reindirizzamento 200 invece di un corretto 300x, quindi il browser memorizzerà il cookie e quindi eseguirà il "reindirizzamento". Il <a>collegamento è un fallback nel caso in cui il browser non esegua il meta refresh.
Ho appena riscontrato questo problema con Firefox e Safari, ma non con Chrome. Dai miei test, questo accade solo quando il dominio cambia durante il reindirizzamento. Questo è tipico in un flusso OAuth2:
Per motivi che non ho ancora capito, alcuni cookie della richiesta 2 vengono ignorati mentre altri no. Tuttavia, se la richiesta 2 restituisce un HTTP 200 con Refreshun'intestazione (il reindirizzamento "meta refresh"), i cookie vengono impostati correttamente dalla richiesta 3.
samesite=strict. Per la richiesta di richiamata il browser pensa ancora che l'originatore sia google (o qualsiasi provider oauth che utilizzi). Quindi, se imposti un cookie samesite = strict nella tua risposta 302, il browser probabilmente pensa "ah ah! Questa è una richiesta cross-site proveniente da Google al tuo sito" e quindi non invia il cookie quando richiede l'URL reindirizzato. La soluzione è utilizzare un meta refresh come hai fatto, quindi la tua richiesta proviene dal tuo sito. Potrei parlare di merda, ma questo è il mio pensiero attuale.
È stato riscontrato questo problema durante l'utilizzo di OpenIdConnect / IdentityServer su .Net, dove un'API separata (nome host diverso) gestisce l'autenticazione e reindirizza al sito principale.
Innanzitutto (per lo sviluppo su localhost) è necessario impostare l' CookieSecureopzione su SameAsRequesto Neverper gestire la http://localhost/non sicurezza. Vedi la risposta di Michael Freidgeim .
Secondo, è necessario impostare l' CookieSameSiteattributo su Lax, altrimenti i cookie non vengono salvati affatto. Strictnon funziona qui!
Nel mio caso ho impostato CookieOptions.Secure = true, ma l'ho testato su http: // localhost ., E il browser nasconde i cookie in base all'impostazione.
Per evitare questo problema, puoi impostare l'opzione Cookie Secure in modo che corrisponda al protocollo Request.IsHttps, ad es
new CookieOptions()
{
Path = "/",
HttpOnly = true,
Secure = Request.IsHttps,
Expires = expires
}
Set-CookieTuttavia, tutto ciò è ortogonale a ciò che fanno i browser con le intestazioni sui reindirizzamenti 302.
secure=request.is_securein fiaschetta.