どうやら、私はそのセマンティクスを完全に誤解しています。私はこのようなものを考えました：

1. クライアントのダウンロードjavascriptのコードMyCode.js http://siteA- 起源。
2. MyCode.jsの応答ヘッダーにはAccess-Control-Allow-Origin：http://siteBが含まれています。これは、MyCode.jsがサイトBへのクロスオリジン参照を作成できることを意味していると思いました。
3. クライアントはMyCode.jsの一部の機能をトリガーしますhttp://siteB。これにより、クロスオリジンリクエストであるにもかかわらず、にリクエストが送信されます。

まあ、私は間違っています。このようにはまったく機能しません。それで、私はクロスオリジンリソースシェアリングを読み、w3c推奨のクロスオリジンリソースシェアリングを読み込もうとしました

確かなことが1つあります。このヘッダーをどのように使用すればよいのか、まだわかりません。

サイトAとサイトBの両方を完全に制御できます。サイトAからダウンロードしたJavaScriptコードがこのヘッダーを使用してサイトBのリソースにアクセスできるようにするにはどうすればよいですか？

PS

JSONPを利用したくありません。

Access-Control-Allow-OriginあるCORS（クロスオリジンリソースの共有）ヘッダが。

サイトAがサイトBからコンテンツを取得しようとすると、サイトBはAccess-Control-Allow-Origin応答ヘッダーを送信して、このページのコンテンツに特定の発行元がアクセスできることをブラウザーに通知できます。（オリジンはドメインとスキームおよびポート番号です。）デフォルトでは、サイトBのページは他のオリジンにはアクセスできません。Access-Control-Allow-Originヘッダーを使用すると、特定の要求元によるクロスオリジンアクセスのドアが開きます。

サイトBがサイトAにアクセスできるようにするリソース/ページごとに、サイトBは応答ヘッダーを含むページを提供する必要があります。

Access-Control-Allow-Origin: http://siteA.com

最新のブラウザはクロスドメインリクエストを完全にブロックしません。サイトAがサイトBにページをリクエストすると、ブラウザは実際にネットワークレベルでリクエストされたページをフェッチし、応答ヘッダーにサイトAが許可されたリクエスタドメインとしてリストされているかどうかを確認します。サイトAがこのページへのアクセスを許可されていることをサイトBが示していない場合、ブラウザーはXMLHttpRequestのerrorイベントをトリガーし、要求しているJavaScriptコードへの応答データを拒否します。

単純でないリクエスト

ネットワークレベルで発生することは、上記で説明したものよりも少し複雑になる可能性があります。リクエストが「非シンプル」リクエストの場合、ブラウザはまずデータのない「プリフライト」OPTIONSリクエストを送信して、サーバーがリクエストを受け入れることを確認します。次のいずれか（または両方）の場合、リクエストは単純ではありません。

• GETまたはPOST以外のHTTP動詞（PUT、DELETEなど）を使用する
• 単純でない要求ヘッダーを使用する。単純なリクエストヘッダーは次のとおりです。
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type（これは、その値がある場合にのみ、単純でapplication/x-www-form-urlencoded、multipart/form-dataまたはtext/plain）

サーバーがOPTIONSプリフライトに、非単純動詞および/または非単純ヘッダーに一致する適切な応答ヘッダー（Access-Control-Allow-Headers非単純ヘッダー、Access-Control-Allow-Methods非単純動詞）で応答した場合、ブラウザーは実際のリクエストを送信します。

サイトAがのPUTリクエストを送信し、/somePage単純でないContent-Type値をとするapplication/jsonと、ブラウザは最初にプリフライトリクエストを送信します。

OPTIONS /somePage HTTP/1.1
Origin: http://siteA.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type

Access-Control-Request-MethodとAccess-Control-Request-Headersはブラウザによって自動的に追加されることに注意してください。それらを追加する必要はありません。このOPTIONSプリフライトは、成功した応答ヘッダーを取得します。

Access-Control-Allow-Origin: http://siteA.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type

実際のリクエストを送信するとき（プリフライトが実行された後）の動作は、単純なリクエストが処理される方法と同じです。言い換えると、プリフライトが成功した単純でない要求は、単純な要求と同じように扱われます（つまり、サーバーAccess-Control-Allow-Originは実際の応答のために再度送信する必要があります）。

ブラウザは実際のリクエストを送信します：

PUT /somePage HTTP/1.1
Origin: http://siteA.com
Content-Type: application/json

{ "myRequestContent": "JSON is so great" }

そして、サーバーAccess-Control-Allow-Originは、単純なリクエストの場合と同様に、を返します。

Access-Control-Allow-Origin: http://siteA.com

非単純なリクエストの詳細については、CORSを介したXMLHttpRequestについてを参照してください。

クロスオリジンリソースシェアリング- CORS（別名クロスドメインAJAXリクエスト）は、ほとんどのWeb開発者が遭遇する可能性のある問題であり、Same-Origin-Policyによると、ブラウザはセキュリティサンドボックス内のクライアントJavaScriptを制限します。通常、JSはリモートサーバーと直接通信できません。別のドメインから。過去に、開発者はクロスドメインリソースリクエストを実現するための多くのトリッキーな方法を作成しました。

1. リモートと通信するための「プロキシ」としてFlash / Silverlightまたはサーバー側を使用します。
2. JSON With Padding（JSONP）。
3. リモートサーバーをiframeに埋め込み、フラグメントまたはwindow.nameを介して通信します。ここを参照してください。

これらのトリッキーな方法には多少の問題があります。たとえば、JSONPは開発者がそれを単に「評価」するとセキュリティホールにつながる可能性があり、上記の＃3は機能しますが、両方のドメインは互いに厳密なコントラクトを構築する必要があり、柔軟でもエレガントでもありません私見では：）

W3Cは、この問題を解決するための安全で柔軟な推奨される標準的な方法を提供する標準ソリューションとして、Cross-Origin Resource Sharing（CORS）を導入しました。

メカニズム

高レベルでは、CORSはドメインAからのクライアントAJAX呼び出しとドメインBでホストされているページとの間の契約であると簡単に見なすことができます。典型的なクロスオリジン要求/応答は次のようになります。

DomainA AJAXリクエストヘッダー

Host DomainB.com
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/json
Accept-Language en-us;
Accept-Encoding gzip, deflate
Keep-Alive 115
Origin http://DomainA.com 

DomainB応答ヘッダー

Cache-Control private
Content-Type application/json; charset=utf-8
Access-Control-Allow-Origin DomainA.com
Content-Length 87
Proxy-Connection Keep-Alive
Connection Keep-Alive

上記でマークした青色の部分はカーネルの事実であり、「Origin」リクエストヘッダーは「クロスオリジンリクエストまたはプリフライトリクエストの発信元を示します」、「Access-Control-Allow-Origin」レスポンスヘッダーはこのページがDomainA（値が*の場合、任意のドメインからのリモート要求を許可することを示します）。

上記で述べたように、W3 は実際にクロスオリジンのHTTPリクエストを送信する前に「プリフライトリクエスト」を実装するようブラウザに推奨しましたOPTIONS。

OPTIONS DomainB.com/foo.aspx HTTP/1.1

foo.aspxがOPTIONS HTTP動詞をサポートしている場合、以下のような応答を返す可能性があります。

HTTP/1.1 200 OK
Date: Wed, 01 Mar 2011 15:38:19 GMT
Access-Control-Allow-Origin: http://DomainA.com
Access-Control-Allow-Methods: POST, GET, OPTIONS, HEAD
Access-Control-Allow-Headers: X-Requested-With
Access-Control-Max-Age: 1728000
Connection: Keep-Alive
Content-Type: application/json

応答に「Access-Control-Allow-Origin」が含まれ、その値が「*」であるか、CORSリクエストを送信したドメインが含まれている場合のみ、この必須条件の条件を満たすことにより、ブラウザは実際のクロスドメインリクエストを送信し、結果をキャッシュします「プリフライト結果キャッシュ」

3年前にCORSについてブログに投稿しました：AJAX Cross-Origin HTTP request

質問は少し古すぎて回答できませんが、今後この質問への参照用に投稿します。

この Mozilla Developer Networkの記事によると、

リソースは、最初のリソース自体が提供するドメインまたはポートとは異なるドメインまたはポートからのリソースを要求すると、クロスオリジンHTTP要求を作成します。

HTMLページから提供をhttp://domain-a.com作る<img>のsrc要求をhttp://domain-b.com/image.jpg。
今日のWeb上の多くのページは、CSSスタイルシート、画像、スクリプトなどのリソースを別々のドメインからロードしています（そのため、すばらしいはずです）。

同一起源ポリシー

セキュリティ上の理由から、ブラウザはスクリプト内から開始されたクロスオリジンHTTPリクエストを制限します。
たとえば、XMLHttpRequestとFetch続く同一生成元ポリシーを。
そのため、独自のドメインへのHTTPリクエストのみを使用する、XMLHttpRequestまたは作成FetchできるWebアプリケーションです。

クロスオリジンリソースシェアリング（CORS）

Webアプリケーションを改善するために、開発者はブラウザベンダーにクロスドメインリクエストを許可するように求めました。

クロスオリジンリソース共有（CORS）メカニズムは、Webサーバが与えるクロスドメインアクセス制御安全なクロスドメインのデータ転送を可能にします、。
最近のブラウザは、使用CORSでAPIコンテナなど- XMLHttpRequestまたはFetchクロスオリジンのHTTPリクエストのリスクを軽減するために- 。

CORSの仕組み（Access-Control-Allow-Originヘッダー）

ウィキペディア：

CORS標準では、ブラウザとサーバーがリモートURLに権限を持っている場合にのみリクエストする方法を提供する新しいHTTPヘッダーについて説明しています。

一部の検証と承認はサーバーで実行できますが、通常、これらのヘッダーをサポートし、それらが課す制限を守るのはブラウザの責任です。

例

1. ブラウザOPTIONSは、Origin HTTPヘッダー付きのリクエストを送信します。

   このヘッダーの値は、親ページを提供したドメインです。のページがhttp://www.example.comのユーザーデータにアクセスしようとするservice.example.comと、次のリクエストヘッダーがに送信されservice.example.comます。

   起源：http : //www.example.com

2. のサーバーservice.example.comは次のように応答します：

   • Access-Control-Allow-Origin許可される起点サイトを示す応答内の（ACAO）ヘッダー。
     例えば：

     Access-Control-Allow-Origin: http://www.example.com

   • サーバーがクロスオリジンリクエストを許可しない場合のエラーページ

   • Access-Control-Allow-Originすべてのドメインを許可するワイルドカード付きの（ACAO）ヘッダー：

     Access-Control-Allow-Origin: *

CORSについて考え始めると、質問で説明したように、ヘッダーをホストしているサイトに関する私の直感は正しくありません。私にとって、同じオリジンポリシーの目的について考えることは役に立ちます。

同じ生成元ポリシーの目的は、siteB.comとのみ共有するように選択した個人情報にアクセスするsiteA.com上の悪意のあるJavaScriptからユーザーを保護することです。同じオリジンポリシーがない場合、siteA.comの作成者が記述したJavaScriptは、siteB.comの認証Cookieを使用して、ブラウザーからsiteB.comにリクエストを送信する可能性があります。このようにして、siteA.comは、siteB.comと共有する秘密情報を盗む可能性があります。

CORSの出所であるクロスドメインで作業する必要がある場合があります。CORSは、domainB.comの同じ発信元ポリシーを緩和し、Access-Control-Allow-Originヘッダーを使用して、domainAと対話できるJavaScriptの実行が信頼されている他のドメイン（domainA.com）をリストします。 com。

CORSヘッダーを提供するドメインを理解するには、これを考慮してください。mybank.comにクロスドメインリクエストを送信しようとするJavaScriptが含まれている、malicious.comにアクセスします。同じオリジンポリシーを緩和するCORSヘッダーを設定して、malicious.comのJavaScriptがそれとやり取りできるようにするかどうかを決定するのは、malicious.comではなくmybank.comの責任です。malicous.comが独自のCORSヘッダーを設定して、mybank.comへの独自のJavaScriptアクセスを許可できる場合、これは同じオリジンポリシーを完全に無効にします。

私の直感が悪いのは、サイトを開発するときの視点だと思います。それはです私のすべてと、サイト私のため、それは悪意のある何もしていないと、それは、最大でなければなりません、JavaScriptの私の他のどのサイトを指定するために私の JavaScriptがと対話することができます。実際に、JavaScriptが自分のサイトとやり取りしようとしている他のサイトを考えるべきであり、CORSを使用してそれらを許可する必要があるのですか？

1.クライアントは、http：// siteA-オリジンからJavaScriptコードMyCode.jsをダウンロードします。

ダウンロードを実行するコード-あなたのhtmlスクリプトタグまたはjavascriptからのxhrなど-から来たとしましょう。たとえば、http：// siteZです。また、ブラウザーがMyCode.jsを要求すると、「Arigin：http：// siteZ」というOrigin：ヘッダーが送信されます。（これを停止または妨害することはできません。）

2. MyCode.jsの応答ヘッダーにAccess-Control-Allow-Origin：http：// siteBが含まれています。これは、MyCode.jsがサイトBへのクロスオリジン参照を作成できることを意味していると思いました。

番号。つまり、siteBのみがこのリクエストを実行できます。そのため、siteZからのMyCode.jsのリクエストは代わりにエラーを受け取り、ブラウザは通常何もしません。ただし、サーバーでACAO：siteZを返すようにすると、MyCode.jsが返されます。または、「*」を送信する場合、それは機能し、すべての人を許可します。または、サーバーが常にOrigin：ヘッダーから文字列を送信する場合...しかし、セキュリティのため、ハッカーを恐れている場合、サーバーは、それらの要求を行うことが許可されている候補者リストのオリジンのみを許可する必要があります。

次に、MyCode.jsはsiteAから取得されます。siteBにリクエストを送信すると、それらはすべてクロスオリジンであり、ブラウザーはOrigin：siteAを送信します。siteBはsiteAを取得し、許可されたリクエスターの短いリストにあることを認識して、ACAO：siteAを返信する必要があります。そうして初めて、ブラウザはスクリプトにそれらのリクエストの結果を取得させます。

ReactとAxiosを使用して、プロキシリンクをURLに結合し、以下に示すようにヘッダーを追加します

https://cors-anywhere.herokuapp.com/ + Your API URL

プロキシリンクを追加するだけで機能しますが、アクセス不可の場合もエラーがスローされる可能性があります。したがって、以下に示すようにヘッダーを追加することをお勧めします。

axios.get(`https://cors-anywhere.herokuapp.com/[YOUR_API_URL]`,{headers: {'Access-Control-Allow-Origin': '*'}})
      .then(response => console.log(response:data);
  }

警告：本番環境では使用しないでください

これは簡単な解決策であり、応答が得られない理由に苦労している場合は、これを使用できます。しかし、これは生産にとって最良の答えではありません。

いくつかの反対票を得て、それは完全に理にかなっています、私はずっと前に警告を追加するべきでした。

ブラウザーが要求をブロックするクロスドメインアプリケーションをテストする場合は、ブラウザーを非セーフモードで開き、コードを変更せずに、コードを安全にせずにアプリケーションをテストできます。MAC OSからは、ターミナルラインからこれを行うことができます。

open -a Google\ Chrome --args --disable-web-security --user-data-dir

PHPを使用している場合は、phpファイルの先頭に次のコードを追加してみてください。

localhostを使用している場合は、次のことを試してください。

header("Access-Control-Allow-Origin: *");

サーバーなどの外部ドメインを使用している場合は、次のことを試してください。

header("Access-Control-Allow-Origin: http://www.website.com");

私はExpress 4とノード7.4とAngularで作業していますが、これと同じ問題がありました：
a）サーバー側：ファイルapp.jsで次のようなすべての応答にヘッダーを指定します。

app.use(function(req, res, next) {  
      res.header('Access-Control-Allow-Origin', req.headers.origin);
      res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
      next();
 });  

これはすべてのルータの前にある必要があります。
私はこのヘッダーがたくさん追加されているのを見ました：

res.header("Access-Control-Allow-Headers","*");
res.header('Access-Control-Allow-Credentials', true);
res.header('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE');

しかし、私はそれを必要とし
ません、b）クライアント側：ajaxを送信する場合、次のように追加します： "withCredentials：true"：

$http({
     method: 'POST',
     url: 'url, 
     withCredentials: true,
     data : {}
   }).then(function(response){
        // code  
   }, function (response) {
         // code 
   });

幸運を。

クロスオリジン共有の場合、ヘッダーを設定します。 'Access-Control-Allow-Origin':'*';

PHP： header('Access-Control-Allow-Origin':'*');

ノード： app.use('Access-Control-Allow-Origin':'*');

これにより、異なるドメインのコンテンツを共有できます。

Pythonでは、Flask-CORSライブラリを使用して大成功を収めています。CORSを非常に簡単かつ簡単に扱うことができます。以下のライブラリのドキュメントからいくつかのコードを追加しました。

インストール：

$ pip install -U flask-cors

すべてのルートのすべてのドメインにCORSを許可する簡単な例：

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

@app.route("/")
def helloWorld():
  return "Hello, cross-origin-world!"

より具体的な例については、ドキュメントを参照してください。上記の簡単な例を使用して、別のフラスコサーバーにアクセスする必要のあるイオンアプリケーションでCORSの問題を回避しました。

私自身の経験から、CORSが問題である理由を簡単に説明することは困難です。

なぜそこにあるのかを理解すると、ヘッダーとディスカッションがより明確になります。数行で説明します。

それはすべてクッキーに関するものです。Cookieはドメインごとにクライアントに保存されます。

事例の例：お使いのコンピューターには、のCookieがありyourbank.comます。多分あなたのセッションはそこにあります。

重要なポイント：クライアントがサーバーにリクエストを送信すると、クライアントが存在するドメインに保存されているCookieが送信されます。

ブラウザでにログインしていますyourbank.com。すべてのアカウントを表示するように要求します。 yourbank.comクッキーの山を受け取り、その応答（アカウント）を送り返します。

別のクライアントがサーバーに対してクロスオリジン要求を行う場合、それらのCookieは以前と同様に一緒に送信されます。ルーロ。

にアクセスしmalicious.comます。Maliciousは、を含むさまざまな銀行に多数のリクエストを作成しyourbank.comます。

Cookieは期待どおりに検証されるため、サーバーは応答を承認します。

これらのCookieは収集されて一緒に送信されます-現在、malicious.comからの応答がありyourbankます。

うわぁ。

そこで、いくつかの質問と回答が明らかになります。

• 「ブラウザでそれができないようにブロックしないのはなぜですか？」うん。CORS。
• 「どうやってそれを回避するのですか？」CORSに問題がないことをサーバーにリクエストしてもらいます。

次のコードをweb.configファイルに貼り付けるだけです。

<system.webServer>タグの下に次のコードを貼り付ける必要があることに注意してください

    <httpProtocol>  
    <customHeaders>  
     <add name="Access-Control-Allow-Origin" value="*" />  
     <add name="Access-Control-Allow-Headers" value="Content-Type" />  
     <add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />  
    </customHeaders>  
  </httpProtocol>  

Access-Control-Allow-Origin応答ヘッダーは、指定されたオリジンからの要求コードと応答を共有できるかどうかを示します。

Header type Response       header
Forbidden header name      no

任意のオリジンからのコードがリソースにアクセスすることを許可するようブラウザに指示する応答には、以下が含まれます。

Access-Control-Allow-Origin: *

詳細については、こちらをご覧ください ....

NginxとAppache

アプシラーの回答に加えて、リクエストが単純であるかどうかを示すウィキグラフを追加したいと思います（およびOPTIONSプリフライトリクエストが送信されるかどうか）。

単純なリクエスト（例：画像のホットリンク）では、サーバー設定ファイルを変更する必要はありませんが、Melvin Guerreroが彼の回答で言及しているように（サーバーでホストされている、phpなどで）アプリケーションにヘッダーを追加できますが、覚えておいてください：サーバー（構成）のcorsヘッダーと同時に、アプリケーション（phpなど）で単純なcorsを許可しますが、これはまったく機能しません。

そしてここに2つの人気のあるサーバーの設定があります

• NginxでCORSをオンにする（nginx.confファイル）

  コードスニペットを表示

  location ~ ^/index\.php(/|$) {
     ...
      add_header 'Access-Control-Allow-Origin' "$http_origin" always; # if you change "$http_origin" to "*" you shoud get same result - allow all domain to CORS (but better change it to your particular domain)
      add_header 'Access-Control-Allow-Credentials' 'true' always;
      if ($request_method = OPTIONS) {
          add_header 'Access-Control-Allow-Origin' "$http_origin"; # DO NOT remove THIS LINES (doubled with outside 'if' above)
          add_header 'Access-Control-Allow-Credentials' 'true';
          add_header 'Access-Control-Max-Age' 1728000; # cache preflight value for 20 days
          add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';  # arbitrary methods
          add_header 'Access-Control-Allow-Headers' 'My-First-Header,My-Second-Header,Authorization,Content-Type,Accept,Origin'; # arbitrary headers
          add_header 'Content-Length' 0;
          add_header 'Content-Type' 'text/plain charset=UTF-8';
          return 204;
      }
  }

  コードスニペットを実行する結果を非表示

  スニペットを展開

• AppacheでCORSを有効にする（.htaccessファイル）

  コードスニペットを表示

  # ------------------------------------------------------------------------------
  # | Cross-domain Ajax requests                                                 |
  # ------------------------------------------------------------------------------
  
  # Enable cross-origin Ajax requests.
  # http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity
  # http://enable-cors.org/
  
  # change * (allow any domain) below to your domain
  Header set Access-Control-Allow-Origin "*"
  Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
  Header always set Access-Control-Allow-Headers "My-First-Header,My-Second-Header,Authorization, content-type, csrf-token"
  Header always set Access-Control-Allow-Credentials "true"

  コードスニペットを実行する結果を非表示

  スニペットを展開