クロスドメインのリソース共有（CORS）を設定することを念頭に置いOSSの最初の使用は、効果の問題になりません非難するCDN

オリジナル：

https://www.lastupdate.net/4669.html

昨日H5グループは、フィードバックの問題を開発し、ブラウザはクロスドメイン構成のヒントを受け取ることができないと言う：//：ロードHTTPSに失敗しましたnnmjstore.xxx.com /レコード/ 34e38a6b-0aaf-4bc3-af73-1d9dffcdb6f8_cdhzmj_15：いいえ" --controlアクセス起源「ヘッダーは、要求されたリソース原点に現在オンになっている。」許可HTTP：// cdhzmjstore.xxx.com「はそのため許可されアクセスされていません。

すなわち：cdhzmjstore.xxx.comのAjaxを使用して、失敗したnnmjstore.xxx.com上のファイルにアクセスするために（私は具体的には、ファイルをアップロードすることがあります推測要求していません）。

nnmjstore.xxx.comファイルは、私はすでにクロスドメインを設定し、すぐにチェックするために行って、何の問題を発見していない覚えて、上記の雲アリOSSに格納されています。次のような問題を解決するには、単に、すべてのソースを手放します：

しかし、同じプロンプトエラーが発生する、またはそれ以上の悲しいリマインダーに。。。

そこで彼は、次のアリクラウドOSS文書を回し、次のように要約されます。

同一生成元ポリシー

クロスドメインアクセス、またはクロスドメインアクセスの問題JavaScriptは、ブラウザはセキュリティ上の理由のために設定された制限は、その同一生成元ポリシーです。JavaScriptコードのウェブサイトからのページがBサイトにアクセスしようとすると、A、B 2つのサイトが異なるドメインに属しているので、ブラウザは、訪問を拒否します。

実用的なアプリケーションでは、このようなユーザのサイトのwww.a.com、OSSを使用してバックエンドとしてのクロスドメインアクセスの需要が、しばしばあります。Webページにアップロード機能を達成するためにはJavaScriptの使用を提供するが、このページでは、あなただけのwww.a.comに要求を送信することができ、要求は他のサイトに送信され、ブラウザを拒否されます。これはwww.a.comからのデータ必見のトランジットをアップロードするユーザーをリードしています。あなたは、クロスドメインアクセスを設定した場合、ユーザーは、通過せずにwww.a.comからOSSに直接アップロードすることができます。

クロスオリジンリソースの共有を達成

クロスドメインのリソース共有（クロスオリジンリソースの共有）、CORS、HTML5がクロスドメインアクセスを実現するために、標準のクロスドメインソリューション、OSSサポートCORS基準を提供と呼ばれます。特定のルールは、CORSを参照することができるW3C仕様CORSを。次のようにその実装は次のようになります。

CORSは、上記の例のように、そのソースドメインを示すためにHTTP要求によってヘッダの起源が来る、ヘッダOriginはwww.a.comあります。
サーバが要求を受信した後、その要求は、ソースドメインを可能にする特定のルールに従うか否かを判断します。許可された場合は、サーバが応答がアクセス制御 - 許可 - 起源との意見がwww.a.comクロスドメインアクセスを表現できるようにするには、このヘッダー、コンテンツが含まれています返されます。サーバが許可されている場合、クロスドメインのすべてが要求したアクセス制御 - 許可 - 起源ヘッダーは*に設定されています、
クロスドメインリクエストが成功したかを決定するために、ブラウザには、追加の対応するヘッダた場合、ブラウザが対応するヘッダを返すかどうかに基づいて、要求をインターセプトします。非単純な要求した場合、ブラウザは最初のCORSの設定、サーバーがサポートしていない場合は、次の操作を取得するために、サーバーにOPTIONSリクエストを送信すると、ブラウザは次の要求をインターセプトします。

CORS OSSは、対応するクロスドメインの要求に応じて要求を許可または拒否するように構成ルールを提供します。ルールは、バケットレベルで設定されています。詳細については、を参照してくださいPutBucketCORS。

ここではいくつかの重要なポイントは以下のとおりです。

CORS関連ヘッダーの追加ブラウザはすべて自動的に行われ、ユーザーは任意の追加の操作は必要ありません。CORSの操作は、ブラウザ環境では意味があります。
認証されたかどうか、およびOSSは、OSS CORS CORSは、ルールが追加CORSは、ヘッダのルールに関連するかどうかを決定するために使用される要求、すなわち、完全に独立しています。インターセプトかどうかの要求は完全にブラウザによって決定されます。
クロスドメインリクエストを使用する場合は、ブラウザのキャッシュ機能を開くかどうかに焦点を当てる必要があります。同じブラウザページ上で実行している場合は2 www.a.comとwww.b.comからですwww.a.com要求がサーバーに到達した場合、同時に、同じクロスドメインのリソースを要求している、サーバーリソースアクセス制御 - 許可 - 起源持参ヘッダーはwww.a.comとしてユーザーに返されます。今回www.b.comは、リクエスト、キャッシュは、ユーザーに返されます後、ヘッダーとCORSコンテンツの要件が一致しない、それが失敗する後続の要求につながるブラウザ上の要求を開始しました。

突然、この時間を覚えて、アクセスを高速化するために、我々はOSSの先端にアリクラウドCDNサービスを使用して、このような場合は、それはクロスドメインの設定は、CDN上で行われる必要がある、ある、OSS CDNの設定をカバーすることが可能です。

一方のパートナーの過去の半分がドキュメントを見つけることができない、それが設定されていないだろう、それは作業指示照会を行いました。超高速これまで以上に高速応答技術エンジニア、毎回、および方法を教えてくれ、と私は本当に同じ思います。

CDNコンソールで、nnmjstore.xxx.com、セットポイントを見つけた - 「キャッシュ・コントロール - 」以下に示すように、することができ、*は、アクセス制御、許可原点は、パラメータHTTPヘッダーを追加し、HTTPを設定します。

発効を追加した後、テストの後、問題が解決します！