クライアントのWebサイトにパフォーマンス情報をビーコンで返すRUM(Real User Monitoring)JavaScriptを含めています。 CORSの問題が発生することを期待していましたが、警告やエラーなしで機能しているようです。
シナリオ
アプリ-sit.domainC.domainB.domainA.com
パフォーマンスプローブ-probe.domainE.domainD.domainA.com
JSコードは、アプリと同じドメインでホストされています。
このページはAccess-Control-Allow-Originで提供されていないため、なぜこれが機能するのかわかりません。
CORSは、リクエストターゲットがAccess-Control-Allow-Origin
(ACAO)ヘッダーで応答するかどうかを判断することで機能します。この場合、要求ターゲットはパフォーマンスプローブです。ページがACAOヘッダーで提供されているかどうかは関係ありません。
から ウィキペディア :
CORSアーキテクチャでは、ACAOヘッダーは元のWebアプリケーションサーバー(foo.com)ではなく、外部Webサービス(bar.com)によって設定されていることに注意してください。 CORSは、外部WebサービスがWebアプリケーションにそのサービスの使用を許可することを許可し、Webアプリケーションによってアクセスされる外部サービスを制御しません。後者の場合、コンテンツセキュリティポリシーを使用する必要があります(connect-srcディレクティブ)。
同一生成元ポリシー が正しく実装されていると仮定すると、CORSをサポートしないユーザーエージェント(ブラウザー)は、クロスオリジンリクエストを行うときにエラーを生成するだけです。
CORSをサポートするユーザーエージェントは、リクエストの送信元のサイトの値を含むOrigin
ヘッダーを使用してクロスオリジンリクエストを行い、次のいずれかの状況が発生します。
Access-Control-Allow-Origin
ヘッダーが含まれていません。この場合、サーバーはクロスオリジンリクエストを許可しないため、ブラウザは単にエラーを生成します。Access-Control-Allow-Origin
の*
ヘッダーが含まれています。この場合、どのサイトでもサーバーに対してクロスオリジンリクエストを行うことができるため、コードは実行を継続します。Access-Control-Allow-Origin
ヘッダーが含まれています。この場合、現在のサイトがオリジンのリストに含まれていると、サーバーに対してオリジン間リクエストを行うことができるため、コードは実行を継続します。そうしないと、エラーが発生します。上記の点は、実際のプロセスを少し単純化しすぎています。より多くのAccess-Control-*
ヘッダーが含まれる可能性があります。
複雑なメソッド(つまり、単純でないメソッド)の場合、プリフライトと呼ばれる追加の手順があり、実際のリクエストの前にプリフライトリクエストが行われます。
これがプロセスを示すフローチャートです。 OPTIONS呼び出しは、プリフライトプロセスを表します。
(許可を得て使用されている画像、BluesmoonによってCC-BY-SA 4.0の下でライセンス供与 [ソース] )
HTML5 Rocksで CORSを使用 について詳しく読むことができます。 CORS仕様 も非常に役立ちますが、結局のところ仕様であるため、表現は技術的です。