CORS ルールの設定

操作方法

シナリオ

クロスオリジンアクセスは、実際のシナリオでよく使用されます。

たとえば、Web サイト www.a.com のバックエンドで OSS を使用します。 Web ページ上で JavaScript を使用してオブジェクトをアップロードできます。 ただし、アップロード Web ページ上のリクエストは、www.a.com にのみ送信できます。 ブラウザーは、他の Web サイトに送信されるすべてのリクエストを拒否します。 したがって、ユーザーがアップロードするデータは、www.a.com を介して転送される必要があります。 クロスオリジンアクセスが設定されている場合、データを直接 OSS にアップロードでき、www.a.com を介して転送する必要がありません。

CORS の実装

CORS は次のように実装されます。

1. CORS が有効になっている場合、オリジンを指定するための Origin フィールドが HTTP リクエストのヘッダーに 含まれています。 前の例では、Origin フィールドに www.a.com が設定されています。
2. サーバーはリクエストを受信した後、CORS ルールに基づいてオリジンからのリクエストを許可するかどうかを判断します。 リクエストが許可された場合、レスポンスヘッダーの Access-Control-Allow-Origin フィールドの値は www.a.com (このクロスオリジンを許可) です。 サーバーですべてのクロスオリジンリクエストが許可された場合、レスポンスヘッダーの Access-Control-Allow-Origin フィールドの値はアスタリスク (*) です。
3. ブラウザーは、Access-Control-Allow-Origin フィールドがレスポンスヘッダーに返されるかどうかをチェックして、クロスオリジンリクエストが許可されたかどうかを判断します。 このフィールドが返されない場合、ブラウザーはリクエストをブロックします。 リクエストが単純なリクエストではない場合、ブラウザーはまず OPTIONS リクエストを送信して、サーバーの CORS 設定を取得します。 サーバーが以降の CORS 操作を許可しない場合、ブラウザーは以降の単純でないリクエストをブロックします。

OSS では、CORS ルールを設定して、必要に応じてクロスオリジンリクエストを許可するか拒否するかを決定できます。 CORS ルールは、バケットレベルで設定できます。 詳細は、「PutBucketcors」 をご参照ください。

詳細分析

• ブラウザーには、CORS 関連のヘッダーフィールドが自動的に含まれています。 他の操作を実行する必要はありません。 CORS 操作はブラウザーにのみ適用されます。
• CORS リクエストが許可されるかどうかは、OSS 認証とは完全に独立しています。 OSS は CORS ルールを使用して、CORS 関連のヘッダーフィールドが含まれているかどうかを判断します。 ブラウザーは、そのリクエストをブロックするかどうかを判断します。
• クロスオリジンリクエストを送信する前に、ブラウザーのキャッシュ機能が無効になっていることを確認する必要があります。 たとえば、同じブラウザー内の 2 つの Web ページ (www.a.com がオリジンの Web ページと、www.b.com がオリジンの Web ページ) は、同じクロスオリジンリソースに対するリクエストを同時に送信します。 サーバーが最初に www.a.com からリクエストを受信した場合、レスポンスヘッダーの Access-Control-Allow-Origin フィールドの値が www.a.com のリソースを返します。 サーバーが後で www.b.com からリクエストを受信すると、ブラウザーは、レスポンスヘッダーの Access-Control-Allow-Origin フィールドの値が www.a.com のキャッシュリソースを返します。 レスポンスヘッダーフィールドの値が www.b.com からのリクエストの CORS ルールと一致しないため、このリクエストは失敗します。

FAQ

一般的なエラーのトラブルシューティングについては、「OSS CORS エラーとトラブルシューティング」をご参照ください。