私はAccess-Control-Allow-Origin HTTPヘッダーのポイントを確認するのが難しいです。Access-Control-Allow-Origin HTTPヘッダーのポイントは何ですか？
クライアント（ブラウザ）がサーバーから「いいえ」を1回取得した場合、それ以上の要求は送信されないと考えました。しかし、クロムとファイヤーフォックスはリクエストを送信し続けます。
誰かがこのようなヘッダーが意味を成す実生活の例を教えてもらえますか？
ありがとうございました！
Access-Control-Allow-Originヘッダーには、リソースへのアクセスを「許可」する起点のリストが含まれている必要があります。
したがって、どのドメインがサーバーにリソースを要求できるかを判断します。
例えば、Access-Control-Allow-Origin: *のヘッダーを返すと、すべてのサイトが要求されたリソースにアクセスできるようになります。
一方、Access-Control-Allow-Origin: http://foo.example.comを返信すると、http://foo.example.comにしかアクセスできません。
で、このオーバーにいくつかのより多くの情報がたとえばあります
のは、私たちがアーティストによる音楽アルバムのJSONコレクションを返す私たち自身のドメイン上のURLを持っているとしましょう。それは次のようになります。
http://ourdomain.com/GetAlbumsByArtist/MichaelJackson.json
私たちは、このJSONデータを取得するために、当社のウェブサイト上でいくつかのAJAXを使用して、当社のウェブサイト上に表示される場合があります。
しかし、別のサイトの誰かがJSONオブジェクトを自分で使用したい場合はどうすればよいですか？おそらく、私たちが所有している別のウェブサイトhttp://subdomain.ourdomain.comを持っていて、私たちのフィードをourdomain.comから使いたいと思っています。
伝統的に私たちはこのデータに対してクロスドメイン要求を行うことはできません。
私たちのリソースへのアクセスを許可する他のドメインを指定することによって、クロスドメイン要求の扉を開くことができます。
CORSは、クロスオリジンの2部構成のセキュリティビューを実装しています。それが解決しようとしている問題は、（a）ブラウザがクロスオリジン要求を許可しないと想定していたか、（b）それはまったくありません。
クロス・オリジン・コミュニケーションを許可したい人もいますが、ブラウザ・ビルダーはブラウザのロックを解除して突然これらのウェブサイトを公開しないと感じません。これを避けるために、彼らは2つの部分からなる構造を発明しました。ブラウザがサーバーとのクロスオリジン相互作用を許可する前に、そのサーバーは、具体的にはで、クロスオリジンアクセスを許可することを示します。単純なケースでは、それはAccess-Control-Allow-Originです。もっと複雑なケースでは、のプリフライトメカニズムです。
サーバーはリソースに対して適切なリソースアクセス制御を実装する必要があります。 CORSは、サーバがすべての問題を認識していることをブラウザに示すことができるようにするためのものです。
CORSが最初に存在する理由に対処するため、これは受け入れられた回答でなければなりません。 CORSは基本的には「NO TRESPASSING」のサインですが、間違った方向に向いています。主流のブラウザからのリクエストからひどく書かれたサーバーを遡及的に保護するのが唯一の目的です。 CORSは絶対にゼロのセキュリティを提供し、クロスサイト要求パターンを難読化する役割しか果たしません。 –
ありがとうございます！はい、私はすでにmozdevの記事を読んでいます。しかし、私はまだ理解していません。 foo.example.comが理にかなっている現実的な例を与えることができますか？ – clamp
簡単な例を追加しました。私はあなたのために物事を明確にすることを願っています。もしそうでなければ、もっと具体的な質問がありますか？ –
ああ、これは今より意味があります。ありがとう！ – clamp