Chromeの新しいSameSiteの制限について説明している資料で説明が見つからないケースを理解するために助けが必要です。現在、APIに対してクロスサイトリクエストを行うサイトがホストされている場合があります。 APIはCORSヘッダーで応答します。詳細は次のとおりです。
Site: https://a.a.com
API: https://b.a.com
--API response headers
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://a.a.com
--cookie previously set with
Set-Cookie: value=somevalue; Path=/; Expires=<some time/date>; HttpOnly
CORSヘッダーが何かに影響を与えることは期待していませんが(SameSiteの変更について言及していないことを確認したすべてのことに基づいて)、とにかくここに配置します。このシナリオで、フラグを次のように設定した場合:
chrome://flags/#same-site-by-default-cookies
chrome://flags/#cookies-without-same-site-must-be-secure
ブラウザがcookie値の送信をブロックすることを期待します。これは、CookieがSameSite = Laxを持っているかのように扱われ、これらがクロスサイトリクエストであることを期待しているためです。これは実際に発生することではなく、Cookieは正常に送信されます。これをテストするとき、すべての応答と(=有効期限が更新された)Cookieを設定して応答ごとに「Lax + POST」緩和を回避するために、すべての要求とPOST要求の間で3分間待機することも試みました。変更について何を読んでいるのか、このCookieの送信がブラウザによってブロックされない理由と、これらのリクエストが成功する理由がわかりません。
混乱を招くために、開発中に次のシナリオの場合があります。
Site: http://localhost
API: https://a.b.com
--API response headers
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://localhost
--cookie previously set with
Set-Cookie: value=somevalue; Path=/; Expires=<some time/date>; HttpOnly
説明されている最初のシナリオとは異なり、これらの要求は実際にCookieが期待どおりに送信されるのをブロックします(新しいchromeフラグが有効な場合のみ)。ブラウザが表示する警告メッセージは、SameSiteおよびSecureフラグに関連しています。期待します。
誰かが最初のシナリオが機能しているのに2番目のシナリオが機能しない理由を理解するのに役立ちますか?私の懸念は、それが実際に機能するのはバグであり、機能すべきではないということです。これが事実である場合、将来、警告なしに「動作中」から「失敗」に移行する可能性があります。
Chrome変更/フラグの詳細はこちらです:
ここで述べたように https://web.dev/samesite-cookies-explained/ :
ユーザーがwww.web.devにいて、static.web.devから画像を要求する場合、それは同じサイトの要求です。
最初のケースと同じ:
Site: https://a.a.com
API: https://b.a.com
したがって、ブラウザは最初のリクエストを同じサイトのリクエストと見なし、Cookieは削除されませんが、2番目のリクエストはクロスサイトリクエストであり、Samesite属性のないCookieは削除されます。