同一生成元ポリシー

クロスオリジンのアクセス、または JavaScript のクロスオリジンであり、 型安全を考慮し、ブラウザの制限の、つまり、同一生成元ポリシー。ウェブサイト A がサイト B にアクセスするには、その Web ページ上の JavaScript コードを使用しようとすると、 A と B は異なるオリジンの 2 つのウェブサイトがあるので、試みは、ブラウザによって拒否されます。

しかし、クロスオリジン・アクセスは、一般的に日常的に使用しています。たとえば、 OSS は、ウェブサイト www.a.com のためのバックエンドで使用されています。 JavaScript ベースのアップロード機能は、Web ページ上に設けられています。他のウェブサイトに送信されたすべての要求は、ブラウザによって拒否されているのに対しただし、Web ページ上の要求は、 www.a.com に送信されます。その結果、ユーザーがアップロードされたデータは、 www.a.com を介して他のサイトに中継されなければなりません。クロスオリジン・アクセスが設定されている場合は、データが www.a.com を通してそれを中継するのではなく、 OSS に直接アップロードすることができます。

CORS の概要

CORS はHTML5が提供する標準のクロス原点溶液です。特定の CORS ルールについては、 W3C CORS 規範を

CORS は、相互作用のための HTTP ヘッダーを使用ブラウザ、続く制御ポリシーのセットです。識別するときリクエストクロス原点として開始リクエスト 、ブラウザが HTTP 原点ヘッダを付加リクエストと送信リクエストサーバに。前述の例では、オリジナル・ヘッダが www.a.com あります。受信した後、 リクエスト 、サーバが許可するかどうかを一定のルールに基づいて判定するリクエスト 。もしリクエストが許可され、サーバーが応答へのアクセス制御-許可-オリジンのヘッダを付加。ヘッダは、クロスオリジンアクセスが許可されていることを示す、 www.a.com 含ま。ケースでは、サーバはすべてのクロスオリジン・リクエストを許可し、にアクセス制御 - 許可 - オリジンのヘッダを設定します。ブラウザは、クロスオリジン要求は、対応するヘッダが返されるかどうかに基づいて、成功したか否かを判定する。対応するヘッダーが接続されていない場合、ブラウザ・ブロック要求。これは簡単な説明です。

前述の内容は、単純なシナリオです。シンプルなリクエストとプリチェック要求: CORS の規範は、2つのタイプに要求を分類します。事前チェックは、リソースを変更するから不正な要求を防止保護メカニズムです。実際のリクエストを送信する前に、ブラウザがサーバは、クロスオリジン・リクエストを許可するかどうかを判断するために OPTIONS HTTP リクエストを送信します。要求が許可されていない場合は、ブラウザが実際の要求を拒否します。

いいえ事前チェックリクエスト次の両方の条件が満たされている場合にのみ必要です:ありません

  • リクエスト方法は、次のいずれかです。

    • 取得する
    • 役職
  • すべてのヘッダーは、次のリストであります:

    • Cache-Control
    • コンテンツ言語
    • コンテンツタイプ
    • 有効期限
    • 最終更新日
    • プラグマ

事前チェック要求は、サーバーへの後続の要求に関する情報を提供します。

  • 原産地:原点情報を求めます。
  • アクセス・コントロール・リクエスト・メソッド:それに続くのタイプリクエスト 、例えば、POST または GET 。
  • アクセス・コントロール・リクエスト・ヘッダ:ヘッダの一覧明示的に設定し、それ以降に含まリクエスト 。

受信した後、事前チェックリクエスト 、サーバがクロスオリジンを許可するかどうかを決定するリクエスト付属情報に基づいて。リターン情報は、次のヘッダーを使用して送信されます。

  • アクセス制御 - 許可 - オリジン:クロスオリジン・リクエストに対して許可オリジンのリスト。
  • アクセス制御は、-メソッド許可:許可クロスオリジンのリストリクエスト方法。
  • アクセス制御は、-ヘッダを許可:許可クロスオリジンのリストリクエストのヘッダー。
  • アクセス・コントロール・公開・ヘッダ:ヘッダのリストは、 JavaScript のコードに公開することが許可。
  • アクセス・コントロール・マックスエイジ:秒の最大のブラウザのキャッシュ時間。

返された情報に基づいて、ブラウザが実際に送信するかどうかを決定するリクエスト 。これらのヘッダのいずれも受信されない場合、ブラウザは、その後の拒否リクエスト 。

注意
前のアクションは、ブラウザによって自動的に実行され、細部を無視することができます。サーバーが正しく設定されている場合、プロセスは非クロスオリジンの要求に同じです。
シナリオ

アクセス許可制御は、ブラウザではなく、サーバーに適用され、 CORS は、ブラウザが使用されているシナリオでのみ適用されます。したがって、他のクライアントを使用するときに、クロスオリジンの問題を心配する必要はありません。

主に CORS を使用するアプリケーションは、代わりにアプリケーションサーバを介してリダイレクトされるトラフィックを必要とする、直接 OSS にアクセスするには、ブラウザでの Ajax を使用しています。これは、アップロードとダウンロードのプロセスに適用されます。 OSS と Ajax 技術の両方を搭載し、ウェブサイトでは、 CORS は OSS との直接通信のために推奨されます。

CORS のための OSS サポート

OSS は、必要に応じて、対応するクロスオリジン・リクエストを許可または拒否するため CORS ルールの設定をサポートしています。 CORS ルールはバケットレベルで構成されています。詳細については、 PutBucket CORS を

CORS かどうかをリクエスト許可されている OSS の身元確認とは無関係です。すなわち OSS CORS ルールが唯一の関連 CORS ヘッダを添付するかどうかを決定するために使用されています。かどうかはリクエストブラウザのみによって決定されるブロックされています。

クロスオリジン・リクエストを使用する場合は、ブラウザのキャッシュ機能が有効になっていることを確認します。例えば、同一のクロスオリジンリソースは、同じブラウザ内の2つのウェブページによって、それぞれ要求されると同時に( www.a.com と www.b.com 由来)。 www.a.com の要求が最初にサーバによって受信された場合、サーバは、アクセス制御、許可原点ヘッダ「 www.a.com 」のリソースを返します。 www.b.com はその要求を開始すると、ブラウザはその前のキャッシュされたリクエストを返します。ヘッダのコンテンツは CORS 要求と一致しないように、後続の要求は失敗します。

注意
現在、すべての OSS オブジェクト関連のインターフェイスは、 CORS 検証を提供します。加えて、マルチインターフェイスは完全 CORS 検証をサポートします。

クロスオリジンGET リクエストの例

この例では、アヤックスは、 OSS からデータを取得するために使用されます。簡単に説明するために、すべての使用バケットが公開されています。プライベートバケットにアクセスするための CORS の構成は同じであり、唯一の署名が接続されている必要がリクエスト 。

入門

バケットを作成します。例えば、右の公開読み取りに設定されたアクセスとバケット OSS - CORS -テストを作成します。そして、ある test.txt という名前のテキストファイルを作成し、バケットにアップロードします。

クリックしてここにある test.txt のアクセスアドレスを取得します。

注意
テストアドレスと次のアドレスを交換してください。
直接ファイルにアクセスするには、カール使用します。
  1. curl http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/test.txtjust for test

ファイルが正常にアクセスすることができます。

次のコードは、直接の Ajax を使用してこのウェブサイトにアクセスする方法について説明します。これは、アクセスのための最も簡単なHTMLコードです。、次のコードをコピーしてローカルのHTMLファイルとして保存し、ブラウザを通してそれを開くことができます。したがって、何のカスタムヘッダーとが含まれていないので、これはリクエスト事前チェックを必要としません。

  1. <! DOCTYPE html><html><head><script type=”text/javascript” src=”./functions.js”></script></head><body><script type=”text/javascript”>// Create the XHR object.function createCORSRequest(method, url) { var xhr = new XMLHttpRequest(); if (“withCredentials” in xhr) { // XHR for Chrome/Firefox/Opera/Safari. xhr.open(method, url, true); } else if (typeof XDomainRequest ! = “undefined”) { // XDomainRequest for IE. xhr = new XDomainRequest(); xhr.open(method, url); } else { // CORS not supported. xhr = null; } return xhr;}// Make the actual CORS request.function makeCorsRequest() { // All HTML5 Rocks properties support CORS. var url = ‘http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/test.txt‘; var xhr = createCORSRequest(‘GET’, url); if (! xhr) { alert(‘CORS not supported’); return; } // Response handlers. xhr.onload = function() { var text = xhr.responseText; var title = text; alert(‘Response from CORS request to ‘ + url + ‘: ‘ + title); }; xhr.onerror = function() { alert(‘Woops, there was an error making the request.’); }; xhr.send();}</script><p align=”center” style=”font-size: 20px;”><a href=”#” onclick=”makeCorsRequest(); return false;”>Run Sample</a></p></body></html>

ファイルを開いた後、(クロームはこの例で使用される)のリンクをクリックしてください。リンクはアクセスできないことを確認してください。

エラーの原因を特定するために Chrome デベロッパーツールを使用してください。



エラーにはアクセス制御、許可原点ヘッダが見つからなかったという事実によるものです。サーバが CORS で構成されていないためです。

ブラウザが送信することを確認するために、ヘッダ・インターフェースに戻るリクエストオリジンヘッダで。したがって、 リクエストクロス原点リクエスト 。ファイルはローカルファイルであるため、Chrome で、オリジンは null です。



問題が配置されたら、直前の操作を試みたことを確認正常に実行するためにバケットのための CORS 設定を構成することができます。理解を容易にするために、次のようにコンソールに CORS 設定を構成する方法について説明します。私たちは、 CORS 設定が複雑でない場合 CORS は、コンソール上で設定することをお勧めします。

CORS の設定は個々のルールで構成されています。システムは一致を検索する場合、各ルールは、最初のルールから始まる試合としてチェックされます。最初に一致したルールが適用されます。最も緩い構成でルールを追加する方法を示しています。



これは、アクセスがすべての原点に許可されていることを示し、すべてのリクエストの種類、およびすべてのヘッダー、および最大キャッシュ時間は1秒です。

設定が完了したら、再度テストを実行します。結果は次のようになります




アクセス要求が正しく送信することができます。

、クロスオリジン・アクセスの問題をトラブルシューティングするために必要とされる場合は、前の図に示すように、 CORS を設定することができます。この構成では、すべてのクロスオリジン・リクエストを許可します。エラーがこの構成の下で発生した場合は、エラーが CORS とは関係ありません。

最も緩い構成に加えて、より洗練された制御機構は、標的制御するように構成することができます。以下は、成功したマッチのための最も厳しい設定を示しています。




ほとんどの場合、我々は最小限の構成で最大限のセキュリティを保証するために、その使用シナリオにおいて適用厳しい設定を使用することをお勧めします。

POST のアップロードのためのクロスオリジン・リクエストを使用します

以下は POST より複雑な例を提供リクエスト署名とが使用されると、ブラウザは、事前チェック送信する必要がありリクエスト 。

PostObjectSample
注意
上記のコードをダウンロードした後、要件を満たすために、すべての次のセクションを変更します。その後、サーバー上で実行します。



以下は、テストのためにバケット OSS - CORS -テストを使用する方法について説明します。テストの前に、初期状態に設定を復元するために、すべての CORS ルールを削除します。

この Web ページにアクセスし、アップロードするファイルを選択します。

開発者向けツールを起動し、次のコンテンツを表示することができます。前の GET の例に基づいて、同じクロスオリジンのエラーを見つけることは容易です。 GET 異なるリクエスト 、 リクエスト事前チェックが必要です。次の図に示すように、OPTIONS応答が CORS ヘッダを持っていないため、操作は失敗します。



それに応じて CORS の設定を変更します。



成功した結果を得るために、再び操作を行うことができます。コンソールは、新たにアップロードされたファイルを表示します。





テスト内容:

  1. $curl http://oss-cors-test.oss-cn-hangzhou.aliyuncs.com/events/1447312129218-test1.txtポストオブジェクトテスト
CORS 設定の注意事項

CORS の設定項目は次のとおりです。

  • 出典:、例えば、設定時に完全なドメイン情報を提供しhttp://10.101.172.96:8001前の図に示すように。

    例えば、 HTTP をプロトコル名を省略しないでください。デフォルトの1が変更されている場合は、ポート番号を含めます。わからない場合は、原点ヘッダーを表示するには、ブラウザのデバッグ機能を使用します。このフィールドは、ワイルドカードをサポートしていますが、一つだけ、このようなシンボルを使用することができます。ニーズに基づいて設定を行うことができます。

  • 方法:要件に基づいて許可された方法を選択します。
  • ヘッダーを許可:許可ヘッダーのリストを示します。ヘッダ漏れを避けるために、我々は、特に指定しない限り、、このフィールドに*を設定することをお勧めします。ヘッダは、大文字と小文字を区別しません。
  • ヘッダーを公開:ブラウザにさらさヘッダーのリストを示します。ワイルドカードは使用できません。具体的な構成は、アプリケーションに応じて選択する必要があります。例えば、唯一の必要なヘッダを公開、ETagのヘッダ。、この情報を公開する必要がない場合は、このフィールドを空白のままにすることができます。、個々のヘッダーを指定することができます。このフィールドでは大文字と小文字を区別しません。
  • キャッシュ時間:通常のケースでは、、例えば、60代の比較的大きな値を設定することができます。

CORS の構成方法は、サービスにアクセスすることができる各原点のための個々のルールを設定します。可能な場合は、単一のルールで複数のオリジンを含めると、複数のルール間での重複や競合を回避しないでください。他の権限のために、あなただけの必要な権限を付与する必要があります。

トラブルシューティングのアドバイス

同様のプログラムをデバッグする際に CORS エラーのある他のエラーをミックスするのは簡単です。

アクセス場合、例えば、 リクエストため間違っ署名拒否される許可検証が CORS 検証に先行するので、戻り結果は、 CORS ヘッダー情報を含まなくてもよいです。この場合、一部のブラウザでは、直接 CORS エラーを報告しますが、サーバー上の実際の CORS の設定が正しいです。次の2つの方法が前の問題に対処するために使用することができます。

  • HTTP 見るリクエストの戻り値を。 CORS 検証がコアプロセスに影響を与えない独立したプロセスであるため、例えば403のような戻り値は、 CORS によって生成されません。、最初のプログラムに関連した原因を排除しなければなりません。もし事前チェックリクエスト以前に送信され、事前チェック閲覧できますリクエストの結果を。正しい CORS ヘッダーが返された場合、実際のリクエストサーバーで許可されています。したがって、エラーは、別のコンポーネントによって引き起こされ得ます。

  • 前述の例で示した最も緩い設定にサーバの CORS 設定を設定します。すべてのオリジンと許可するようにワイルドカードを使用して、 リクエストの種類を。その後、構成を再確認してください。検証がまだ失敗した場合は、エラーの他のタイプが発生している可能性があります。