Access-Control-Allow-Origin HTTPヘッダーのポイントは何ですか？

Question

私はAccess-Control-Allow-Origin HTTPヘッダーのポイントを確認するのが難しいです。

クライアント（ブラウザ）がサーバーから「いいえ」を1回取得した場合、それ以上の要求は送信されないと考えました。しかし、クロムとファイヤーフォックスはリクエストを送信し続けます。

誰かがこのようなヘッダーが意味を成す実生活の例を教えてもらえますか？

ありがとうございました！

Answer 1

Access-Control-Allow-Originヘッダーには、リソースへのアクセスを「許可」する起点のリストが含まれている必要があります。

したがって、どのドメインがサーバーにリソースを要求できるかを判断します。

例えば、Access-Control-Allow-Origin: *のヘッダーを返すと、すべてのサイトが要求されたリソースにアクセスできるようになります。

一方、Access-Control-Allow-Origin: http://foo.example.comを返信すると、http://foo.example.comにしかアクセスできません。

Mozilla Developer Site

で、このオーバーにいくつかのより多くの情報がたとえばあります

のは、私たちがアーティストによる音楽アルバムのJSONコレクションを返す私たち自身のドメイン上のURLを持っているとしましょう。それは次のようになります。

http://ourdomain.com/GetAlbumsByArtist/MichaelJackson.json 

私たちは、このJSONデータを取得するために、当社のウェブサイト上でいくつかのAJAXを使用して、当社のウェブサイト上に表示される場合があります。

しかし、別のサイトの誰かがJSONオブジェクトを自分で使用したい場合はどうすればよいですか？おそらく、私たちが所有している別のウェブサイトhttp://subdomain.ourdomain.comを持っていて、私たちのフィードをourdomain.comから使いたいと思っています。

伝統的に私たちはこのデータに対してクロスドメイン要求を行うことはできません。

私たちのリソースへのアクセスを許可する他のドメインを指定することによって、クロスドメイン要求の扉を開くことができます。

Answer 2

CORSは、クロスオリジンの2部構成のセキュリティビューを実装しています。それが解決しようとしている問題は、（a）ブラウザがクロスオリジン要求を許可しないと想定していたか、（b）それはまったくありません。

クロス・オリジン・コミュニケーションを許可したい人もいますが、ブラウザ・ビルダーはブラウザのロックを解除して突然これらのウェブサイトを公開しないと感じません。これを避けるために、彼らは2つの部分からなる構造を発明しました。ブラウザがサーバーとのクロスオリジン相互作用を許可する前に、そのサーバーは、具体的にはで、クロスオリジンアクセスを許可することを示します。単純なケースでは、それはAccess-Control-Allow-Originです。もっと複雑なケースでは、のプリフライトメカニズムです。

サーバーはリソースに対して適切なリソースアクセス制御を実装する必要があります。 CORSは、サーバがすべての問題を認識していることをブラウザに示すことができるようにするためのものです。