302リダイレクト中にブラウザのCookieを送信する


86

302リダイレクト中にCookieを送り返すことに問題はありますか?たとえば、URLに戻るCookieを作成し、同じ応答でユーザーをリダイレクトした場合、(最新の)ブラウザーはCookieを無視しますか?


少し読んでみると、セッション変数はサーバー側であり、クライアントの予測可能性に依存していないため、Cookieよりも優れていると思います。
ADTC 2016年

回答:


40

ほとんどのブラウザは、302リダイレクトでCookieを受け入れています。私はそれをかなり確信していましたが、少し調べました。すべての最新のブラウザではありません。 SilverlightクライアントHTTPスタックの削除済み/デッド/マイクロソフト接続Q / Aからのインターネットアーカイブリンクは、302リダイレクト応答のSet-Cookieを無視します(2010)

IE6に代わるものがあり、それはWindowsMo​​bileブラウザーだと思います...


1
指定したフォーラムページにURLでアクセスできません。IE6とWindowsMo​​bileブラウザはそうではないということですか?
hiroshi 2013

1
リンクが移動しました。まったく同じ内容の新しいリンクを設定しました。そして私は、モバイル用のIE固有のバージョンが独自のバグのセットを追加することを意味しました
regilero 2013

51

このブログ投稿によると:http//blog.dubbelboer.com/2012/11/25/302-cookie.htmlすべての主要なブラウザ、IE(6、7、8、9、10)、FF(17)、Safari (6.0.2)、WindowsとMacの両方のOpera(12.11)、リダイレクトにCookieを設定します。これは、301リダイレクトと302リダイレクトの両方に当てはまります。


私たちは、正確に言うことができないので、残念ながら、このリストには、クロムが含まれていないすべての主要なブラウザ...
MestreLion

3
@MestreLion:私のChromeブラウザでは動作します。..だから私たちはトンそれが最終的に2019年には、動作するようになりましたと言うことができると思う
マイケル・

40

1つの通知(開発者の命を救うため):

Cookieのドメインがlocalhostの場合、IEとEdgeはリダイレクト応答でSet-Cookieを無視します。

解決:

localhostの代わりに127.0.0.1を使用します。


11
IEとEdgeはこれを「修正」した可能性があるため、127.0.0.1にもCookieを設定しません。ドー!そして、なぜ開発者全員がIEを愛していないのか疑問に思います...あなたの答えはまだ私にとって約4時間の頭を悩ませることで終わりました。ありがとう!
GlenPeterson 2017年

18

ここでは、この問題のためのクロムのバグがある(のSet-CookieはHTTPステータス302との応答のために無視されます)。


1
これが本当であるならば、それは確かに本当に悪いニュースです:-(
MestreLion

彼らはそれを修正したと思います。バグレポートにはまだ「WontFix」と表示されていますが、私のChromeブラウザでは機能します。
マイケル

@Michaelは、ChromiumはChromeではないことに注意してください:lifewire.com/chromium-and-chrome-differences-4172101-つまり、Chromeでは機能する可能性がありますが、Chromiumには必ずしも当てはまりません
Thomas

3

これは非常に嫌なアプローチですが、30倍のCookie設定ブラウザの動作に本当に依存したくないmeta http-equiv="refresh"場合は、Cookieを設定するときにHTMLの「リダイレクト」を使用できます。たとえば、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>

サーバーは適切な300xリダイレクトではなく200でSet-Cookieを送信するため、ブラウザはCookieを保存してから、「リダイレクト」を実行します。<a>リンクは、メタリフレッシュを実行しない場合はブラウザでフォールバックです。


1

FirefoxとSafariの両方でこの問題が発生しましたが、Chromeでは発生しませんでした。私のテストによると、これはリダイレクト中にドメインが変更された場合にのみ発生します。これは、OAuth2フローでは一般的です。

  1. OAuth2 IDプロバイダー(GitHub、Twitter、Google)は、ブラウザーをアプリにリダイレクトします
  2. アプリのコールバックURLは認証を確認し、ログインCookieを設定してから、宛先URLに再度リダイレクトします
  3. 宛先URLは、Cookieを設定せずに読み込まれます。

私がまだ理解していない理由で、リクエスト2の一部のCookieは無視されますが、他のCookieは無視されません。ただし、リクエスト2がRefreshヘッダー付きのHTTP 200を返す場合(「メタリフレッシュ」リダイレクト)、Cookieはリクエスト3によって適切に設定されます。


このwrtoauthコールバックの問題の理由はsamesite=strict。だと思います。コールバックリクエストの場合、ブラウザは引き続き発信者がgoogle(または使用するoauthプロバイダー)であると見なします。したがって、302応答でsamesite = strict cookieを設定した場合、ブラウザはおそらく「ああ、これはGoogleからあなたのサイトへのクロスサイトリクエストです」と考え、リダイレクトされたURLをリクエストするときにCookieを送信しません。修正は、行ったようにメタリフレッシュを使用することです。そのため、リクエストは自分のサイトから送信されます。私はがらくたを話している可能性がありますが、それは私の現在の考えです。
イラン

1

.NetでOpenIdConnect / IdentityServerを使用しているときにこの問題が発生しました。この場合、別のAPI(異なるホスト名)が認証を処理し、メインサイトにリダイレクトします。

まず(ローカルホストでの開発の場合)、CookieSecureオプションを設定するSameAsRequestNeverhttp://localhost/安全でないことに対処する必要があります。MichaelFreidgeimの回答を参照してください。

次に、CookieSameSite属性をに設定する必要がありますLax。そうしないと、Cookieがまったく保存されません。Strictここでは機能しません!


-1

私の場合、CookieOptions.Secure = trueを設定しましたが、http:// localhostでテストし、ブラウザは設定に従ってCookieを非表示にします。

このような問題を回避するために、プロトコルRequest.IsHttpsなどに一致するcookieSecureオプションを作成できます。

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

2
その場合、セキュアフラグを設定しないでください。フラグの要点は、HTTPS経由で接続する場合にのみCookieを使用するようにブラウザに指示することです。条件付きでフラグを設定すると、セマンティクスが多少変更され、HTTPS-> HTTPから移行するCookieは失われますが、HTTP-> HTTPSから移行する場合は失われません。Set-Cookieただし、これはすべて、ブラウザが302リダイレクトのヘッダーで行うことと直交しています。
MartijnPieters

1
-3票の答えが問題を解決するその時。Secure = trueを設定していましたが、ローカルホストではhttpを使用してテストしていることを忘れていました。Noobの間違い。secure=request.is_secureフラスコで使用します。
Eloff
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.