Alibaba Cloud CDN にサービスを追加した後、POP (ポイントオブプレゼンス) で HTTP レスポンスヘッダーを設定することで、オリジン間アクセスを有効にできます。
オリジン間リソース共有とは
オリジン間リソース共有 (CORS) は、ウェブページが自身のオリジン (ドメイン、プロトコル、またはポート) とは異なるオリジンからリソースにアクセスできるようにする標準的なメカニズムです。これにより、オリジン間のデータ転送を安全に行うことができます。詳細については、「オリジン間リソース共有 (CORS)」をご参照ください。
Q:デフォルトで CDN の CORS が有効になっていない場合はどうなりますか。
デフォルトでは、CDN はオリジン間リソース共有 (CORS) を有効にしていません。この設定がない場合、ブラウザーは同一オリジンポリシーを適用し、オリジン間のリクエストをブロックするため、他のウェブサイトがお客様のリソースを読み込むことができなくなります。
オリジン間リソース共有を設定する理由
セキュリティ上の制約により、ブラウザーは通常、同一オリジンポリシーに従います。これにより、異なるドメイン、サブドメイン、プロトコル、またはポートからのリソースの読み込みやアクセスが制限されます。たとえば、example.com は example.org 上のリソースにアクセスできません。オリジン間リソース共有 (CORS) を設定することで、CDN/ サーバーに関連するレスポンスヘッダーを設定できます。リクエストに許可されたルールを満たすヘッダーが含まれている場合、サーバーは対応する HTTP レスポンスヘッダーを返し、オリジン間のリソースの読み込みとアクセスを許可します。
仕組み
オリジンサーバーでの CORS 設定
CDN での CORS 設定
注意事項
-
OSS バケットをオリジンサーバーとして使用する場合、CDN/ コンソールの CORS 設定が OSS コンソールの CORS 設定を上書きします。OSS コンソールで CORS を設定する方法の詳細については、「CORS ルールの設定」をご参照ください。
-
オンプレミスサーバーまたは ECS インスタンスをオリジンサーバーとして使用する場合、静的コンテンツと動的コンテンツを分離し、CDN/ を使用して静的ファイルの配信を高速化することを推奨します。CDN/ コンソールで設定された CORS 機能は、静的ファイルにのみ適用されます。
オリジン間リソース共有の有効化
Alibaba Cloud CDN コンソールにログインします。
左側のナビゲーションペインで [ドメイン名 ] をクリックします。
-
ドメインページで、管理するドメインを見つけ、管理 列の 操作 をクリックします。
-
キャッシュ設定 をクリックし、送信レスポンスヘッダーの変更 タブを選択して、クロスオリジンリクエストに許可されるオリジンとメソッドを設定します。
-
オリジン間リクエストのオリジンの設定
追加 をクリックし、次の表の説明に従ってパラメーターを設定してから、OK をクリックします。
パラメーター
説明
例
[実行内容]
CORS 検証機能を有効にするには、このパラメーターを 追加 に設定します。
[追加]
[応答ヘッダー]
CORS 検証機能を使用するには、
Access-Control-Allow-Originを設定する必要があります。Access-Control-Allow-Origin
[応答ヘッダー値]
CORS 検証が無効の場合:ワイルドカードまたは単一のオリジンのみを指定できます。
-
ワイルドカード
*:任意のオリジンからのリソースへのアクセスを許可します。 -
単一のオリジン:特定の一つのオリジン (ドメイン名) からのみリソースへのアクセスを許可します。
CORS 検証が有効の場合:ワイルドカード、単一のオリジン、複数のオリジン、またはワイルドカードドメインを指定できます。
-
ワイルドカード
*:任意のオリジンからのリソースへのアクセスを許可します。 -
単一のオリジン:特定の一つのオリジン (ドメイン名) からのみリソースへのアクセスを許可します。
-
指定した複数のオリジン:複数の特定のオリジン (ドメイン名) をコンマ
,で区切って設定し、これらのオリジンからのリソースへのアクセスを許可します。 -
ワイルドカードドメイン:ワイルドカードドメインを指定して、パターンに一致するすべてのオリジンからのアクセスを許可します。
-
* -
http://www.aliyun.com -
https://aliyun.com,http://www.aliyun.com -
http://*.aliyun.com
[重複の許可]
-
はい:オリジンサーバーからのヘッダーは保持され、新しく追加された同名のヘッダーもレスポンスに追加されます。
-
いいえ:新しく追加されたヘッダーが、オリジンサーバーからの同名のヘッダーを上書きします。
重要[重複を許可] と [CORS 検証] の設定は相互に排他的です。[重複を許可] を [はい] に設定すると、CORS 検証は無効になります。
[いいえ]
[CORS]
-
CORS は、実行内容 が 追加 に設定され、かつ 応答ヘッダー が "Access-Control-Allow-Origin" に設定されている場合にのみ設定できます。
-
CORS は しない または 有効 に設定できます。デフォルト値は しない です。
-
[しない]:CDN の POP (ポイントオブプレゼンス) は受信リクエストの
Originヘッダーを検証せず、常に設定されたAccess-Control-Allow-Originの値を返します。 -
[有効]:CDN の POP は、以下のルールに基づいてオリジン間リクエストを検証し、それに応じて
Access-Control-Allow-Originの値を返します。-
[応答ヘッダー]:[ヘッダー値] が
*に設定されている場合、ユーザーリクエストのOriginヘッダーの有無やその値に関わらず、POP は常にAccess-Control-Allow-Origin:*を返します。 -
[応答ヘッダー]:[ヘッダー値] に、コンマ (
,) で区切られた 1 つ以上の特定のオリジンが設定されている場合:-
ユーザーリクエストの
Originヘッダーの値が、設定されたオリジンのいずれかと完全に一致する場合、POP はそのオリジンをAccess-Control-Allow-Originヘッダーの値として返します。 -
一致するものが見つからない場合、POP は CORS ヘッダーをレスポンスに追加しません。
-
-
[応答ヘッダー]:[ヘッダー値] がワイルドカードドメインに設定されている場合、POP はリクエストの
Originヘッダーがワイルドカードパターンに一致するかどうかをチェックします。
-
-
有効 を 応答ヘッダー値 に設定し、応答ヘッダー値 フィールドのドメイン名にハイフン (
-) が含まれている場合は、-を%-に置き換えてエスケープする必要があります。 例:-
元のヘッダー値:
http://doc.aliyun-example.com。 -
エスケープされたヘッダー値:
http://doc.aliyun%-example.com。
-
-
[有効化]
-
-
オリジン間リクエストのメソッドの設定
追加 をクリックし、次の表に従ってパラメーターを設定してから、OK をクリックします。
パラメーター
説明
例
[実行内容]
このパラメーターを追加に設定します。
[追加]
[応答ヘッダー]
Access-Control-Allow-Methodsに設定する必要がありますAccess-Control-Allow-Methods
[応答ヘッダー値]
GET, POST, PUTリクエストメソッドをサポートしています。同時にGET, POST, PUTを追加する必要がある場合は、コンマ,で区切ります。GET[重複の許可]
-
はい:オリジンサーバーからのヘッダーは保持され、新しく追加された同名のヘッダーもレスポンスに追加されます。
-
いいえ:新しく追加されたヘッダーが、オリジンサーバーからの同名のヘッダーを上書きします。
[いいえ]
-
-
Q:CORS レスポンスヘッダーを追加した後、以前にキャッシュされた静的リソースに適用されますか。
いいえ。CDN はヘッダーを含む HTTP レスポンス全体をキャッシュします。新しい CORS ヘッダーをすでにキャッシュされているコンテンツに適用するには、それらのリソースの URL をパージする必要があります。そうしないと、ユーザーはキャッシュから古いレスポンスを受け取り続けます。
設定例
例 1
CORS のレスポンスヘッダー値が、コンマ (,) で区切られた 1 つ以上の特定のオリジンに設定されている場合:
-
ユーザーのリクエストの
Originヘッダーの値が指定されたオリジンのいずれかと完全に一致する場合、CDN/ の POP (ポイントオブプレゼンス) は対応する CORS ヘッダーを返します。 -
完全一致が見つからない場合、CORS ヘッダーはレスポンスに含まれません。
CDN/ で、Access-Control-Allow-Origin: http://example.com,https://aliyundoc.com を設定します。
-
ユーザーリクエストの
Originヘッダーがhttp://example.comの場合、CDN/ の POP (ポイントオブプレゼンス) はAccess-Control-Allow-Origin: http://example.comを返します。 -
ユーザーリクエストの
Originヘッダーがhttps://aliyundoc.comの場合、CDN/ ノードはAccess-Control-Allow-Origin: https://aliyundoc.comを返します。 -
CDN/ ノードは、Origin ヘッダーが
http://aliyundoc.comのユーザーリクエストには応答しません (プロトコルの不一致:ユーザーリクエストは HTTP を使用していますが、CDN/ は HTTPS 用に設定されています)。 -
リクエストの
Originヘッダーがhttp://aliyun.comの場合、CDN/ の POP は応答しません (ドメインの不一致)。
例 2
CORS のレスポンスヘッダー値がワイルドカードドメインに設定されている場合、POP はリクエストヘッダーの Origin の値がワイルドカードパターンに一致するかどうかをチェックします。
CDN/ で、Access-Control-Allow-Origin: http://*.aliyundoc.com を設定します。
-
ユーザーリクエストに Origin ヘッダー
http://demo.aliyundoc.comが含まれている場合、CDN/ の POP はAccess-Control-Allow-Origin: http://demo.aliyundoc.comを返します。 -
リクエストの Origin ヘッダーが
http://demo.example.comの場合、ドメイン名が一致しないため、CDN/ の POP は応答しません。 -
CDN/ ノードは、Origin ヘッダーが
https://demo.aliyundoc.comのユーザーリクエストには応答しません。これは、リクエストが HTTPS プロトコルを使用しているのに対し、CDN/ が HTTP プロトコルで設定されているためです。
Q:curl を使用して、CDN からの Access-Control-Allow-Origin ヘッダーが機能していることを確認するにはどうすればよいですか。
curl -svo /dev/null を使用して Origin ヘッダーを含む GET リクエストを送信し、詳細出力でレスポンスヘッダーを確認します。レスポンスに Access-Control-Allow-Origin ヘッダーが期待される値 (例:* または指定したドメイン) で表示されていれば、CORS 設定は機能しています。ヘッダーがない場合は、CDN コンソールのカスタムレスポンスヘッダールールとオリジンサーバーの CORS 設定を確認してください。
curl -svo /dev/null https://img.anleme.cc/agent/dl1.jpg -H 'origin:https://am.anleme.cc'
よくある質問
Access-Control-Allow-Origin レスポンスヘッダーを設定した後もオリジン間エラーが発生し、レスポンスにヘッダーが含まれていないのはなぜですか。
Q:CDN の CORS 設定は、コンマで区切られた複数のワイルドカードドメインをサポートしていますか。
いいえ。CDN で CORS 検証を有効にする場合、単一のワイルドカードドメインのみを設定できます。または、コンマで区切られた複数の完全一致ドメイン (ワイルドカードではない) をリストアップすることもできます。https://*.iflyvoice.cn,https://*.xxx.com のように、コンマで区切られた複数のワイルドカードドメインのリストを指定することはできません。
Q:CDN で高速化されたドメインを介してアクセスされるフォントファイルが CORS の問題を引き起こすのに、ビデオファイルはそうならないのはなぜですか。
この動作は、リソースの種類とブラウザーのセキュリティポリシーによって決まります。デフォルトでは、<video> タグを介して読み込まれるビデオファイル (MP4 や WebM など) は、crossorigin 属性が明示的に追加されない限り、CORS 制限の対象にはなりません。対照的に、フォントファイル (.ttf や .woff など) は、読み込み方法に関係なく、ブラウザーによって常に強制的な CORS 検証の対象となります。したがって、両方のリソースタイプが同じドメインでホストされていても、有効な CORS ポリシーがないとフォントリクエストは失敗しますが、ビデオのリクエストは多くの場合成功します。この違いは、さまざまなコンテンツタイプに対する標準的なブラウザーのセキュリティポリシーに起因します。
Q:CDN の CORS 設定が有効であることを確認するにはどうすればよいですか。
次の方法で確認できます:
-
再度テストして、オリジン間エラーが解決したかを確認します。
-
curl -svo /dev/nullコマンドを使用して、特定のOriginヘッダーを含む GET リクエストを送信し、詳細出力でレスポンスヘッダーを確認します。例:curl -svo /dev/null https://img.anleme.cc/agent/dl1.jpg -H 'origin:https://am.anleme.cc' -
テストドメインをテクニカルサポートに提供して支援を依頼します。
Q:CDN で OSS バケットを高速化する場合、オリジンの OSS から CORS 設定をパススルーするにはどうすればよいですか。
OSS オリジンサーバーから CORS 設定のパススルーを有効にするには、CDN への最初のリクエストに Origin ヘッダーを含める必要があります。これにより、CDN はオリジンからフェッチし、Access-Control-Allow-Origin レスポンスヘッダーをキャッシュできます。ただし、このキャッシュメカニズムは、後続のリクエストが異なる Origin ヘッダーを持つ場合や、Origin ヘッダーを持たない場合に、CORS の問題を引き起こす可能性があります。推奨されるベストプラクティスは、パススルーに頼るのではなく、[キャッシュ設定] の [送信レスポンスヘッダーの変更] 機能を使用して、CDN コンソールで直接 CORS ヘッダーを設定することです。
Q:複数の CDN ドメインが同じ OSS バケットに関連付けられている場合、CORS ルールを OSS で一度だけ設定し、すべての CDN ドメインに自動的に継承させることはできますか。
いいえ。CDN の POP はレスポンスヘッダーをキャッシュし、この動作は最初のリクエストに Origin ヘッダーが含まれているかどうかに影響されるため、OSS からのパススルー設定に依存すると、断続的な CORS エラーが発生する可能性があります。ベストプラクティスは、[送信レスポンスヘッダーの変更] 機能を使用して CORS ヘッダーを追加し、正しく安定した動作を保証することです。