多くの人々は、withCredentialsのようなXmlHttpRequestフラグに精通しており、それが何のためであり、どのヘッダーを使用すべきかを知っているため、ブラウザーは通常サーバーの応答を処理します。 そして、私も知っているように見えたが、私は何を知らなかった-私はグーグルであり、すべてが正常に機能した。 しかし、予想外の動作に遭遇したとき、それについて説明したいと思います。
仕様
www.w3.org/TR/cors/#omit-credentials-flagに示されている
ように 、withCredentialsを使用すると、サーバーへのリクエストで
ユーザー資格情報を使用
できます。 Cookie、認証データ、およびクライアントSSL証明書。
Cookieの受信をリクエストしています：
$.ajax ({ type: 'POST', url: authUrl, dataType: 'json' });
サーバーは次の正しい応答を返します。
Set-Cookie:MYCOOKIE=7B6E846F8972DF580001CDCBF49316E; Path=/; HttpOnly
次に、受信したCookieを使用して同じアドレスに移動します。
$.ajax ({ type: 'GET', url: authUrl, dataType: 'json', cache: false, xhrFields: { withCredentials: true } });
ここで予期しないことが起こります。「withCredentials：true」を指定しましたが、Cookieの最初のリクエストから受信したものは、2番目のリクエストでは送信されません。
最初のリクエストのCookieはブラウザに保存されず、2番目のリクエストで送信するものは何もないことがわかります。
理由はHttpOnlyにあると想定していましたが、このフラグなしではcookieで確認できませんでした。その前に、最初のリクエストに「withCredentials：true」を追加しようとして奇跡が起こりました。
したがって、「withCredentials：true」の表示は、サーバーへの
要求で「ユーザー資格情報」を送信するためだけでなく、サーバーからの応答からそれらを使用するためにも必要であることがわかります。 論理的に思えますが、すべての仕様と説明で「リクエスト」という言葉を使用するのは混乱を招くので、私だけではありません。
PS。 どういうわけかこの
仕様を逃しました。この
仕様では、この属性がない場合、「Cookieは応答で無視されます」と明示的に記載されており、検索スキルに大きな期待を寄せています。 しかし、今では多くの人が誤解の可能性を回避できることを願っています。