SCAPI の CORS

CORS を使用すると、ブラウザーが通常強制する同一サイトポリシーに対する例外を Web サービスで確立できます。CORS を使用しない場合、他のサーバー上のリソースへのブラウザーアクセスは可能ですが、ブラウザーはレスポンスがスクリプトによってアクセスおよび処理されるのを防ぎます。

ブラウザーが、スクリプトが実行されるサイトとは異なるドメインを持つサイトからリソースをリクエストすると、Origin ヘッダーがリクエストに追加されます。CORS をサポートするサーバーは、エンドポイントの使用が許可されているオリジンのリストを含むレスポンスヘッダー Access-Control-Allow-Origin を返します。現在のオリジンがこのリストに含まれていない場合、ブラウザーはコンテンツへのアクセスを阻止します。

次の図は、CORS をサポートする bar.com という名前のサーバーのリクエストフローを示しています。

ブラウザーは、変更リクエストが実行される前に、自動的にプリフライトリクエストを行います。各プリフライトリクエストは、Origin ヘッダーと Access-Control-Request-Method ヘッダーを含む OPTIONS リクエストとして行われます。

結果の CORS レスポンスには、クライアントがオリジンから実行できるメソッドを一覧表示する Access-Control-Allow-Methods ヘッダーが含まれます。 変更リクエスト自体は、次のリクエストフローの例に示すように、プリフライトリクエストが成功した場合にのみ実行されます。

B2C Commerce 24.8 の時点で、SCAPI は CORS 標準とセキュリティのベストプラクティスに準拠し、すべての Data API エンドポイントと Shopper API エンドポイントで CORS リクエストをサポートします。

プリフライト (OPTIONS) リクエストもサポートされています。

構成が指定されていない場合、CORS はアクティブではありません。SCAPI で CORS を構成するには、CORS API を使用します。

構成されたエイリアスのリストには、すべての既知のデフォルト名とサイトエイリアスが自動的に追加されます。CORS 用に明示的に構成する必要はありません。

許可される CORS オリジンの構成は各環境に固有であり、環境間ではレプリケートされません。許可されるオリジンの構成は、クライアント ID とサイトごとに行われます。これは、次のことを意味します。

• アプリケーションごとに許可されたオリジンの個別のリストを管理できます。
• 個別の API またはエンドポイント構成を持つことはできません。

CORS API には AM OAuth トークンが必要です。PUT リクエストを使用して新しい CORS 構成を送信すると、以下の例のようにレスポンスは保存されている構成をミラーリングします。

カスタムオリジンを指定せずにクライアントに対して CORS を有効にするには、空のオリジンリストを使用してクライアントとサイトを構成します。既知のドメイン名とエイリアスは引き続き適用されます。

CORS リクエスト (GET、PUT、POST、DELETE、HEAD リクエストなど) は、一般的なリクエストと同じ結果を生成します。

リクエストに有効な Origin ヘッダーが含まれている場合、レスポンスには次のヘッダーが含まれます。

リクエストに無効な Origin ヘッダーが含まれている場合は、これらのレスポンスヘッダーは単に欠落しており、他の変更はありません。

注: この動作は、無効なオリジンでリクエストを操作すると 401 ステータスコードとメッセージ Unauthorized Origin が発生する OCAPI CORS とは異なります。

有効なエンドポイントを持つプリフライトリクエストの場合、サーバーは次のヘッダーを含む 200 Success ステータスを返します。

エンドポイントが無効な場合、呼び出しは 404 Not Found ステータスを返します。

カスタム API は現在サポートされていません。