javascript - 回避 - cors ヘッダー 'access-control-allow-origin' が足りない



Access-Control-Allow-Originヘッダーはどのように機能しますか? (8)

明らかに、私はその意味論を完全に誤解しています。 私はこのようなものを考えました:

  1. クライアントはhttp:// siteAから原点である javascriptコードMyCode.jsをダウンロードします。
  2. MyCode.jsのレスポンスヘッダーには、 Access-Control-Allow-Origin:http:// siteBが含まれています。これは、MyCode.jsがサイトBへの相互参照を行うことを許可されたと考えていました。
  3. クライアントはMyCode.jsのいくつかの機能を起動します。この機能は、http:// siteBへのリクエストを行います。

まあ、私は間違っています。 これはまったく同じようには機能しません。 だから、私はCross-originリソース共有を読んで、w3c勧告でCross-Origin Resource Sharingを読もうとしました

一つのことは確かです - 私はまだこのヘッダーをどのように使用するのか分かりません。

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

PS

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


Answer #1

Cross-Origin Request Sharing - CORS (AKAクロスドメインAJAXリクエスト)は、同じOrigin-Policyに従って、ほとんどのWeb開発者が遭遇する可能性のある問題です。ブラウザはセキュリティサンドボックス内のクライアントJavaScriptを制限します。通常JSは、サーバーを別のドメインから削除します。 これまでの開発者は、クロスドメインリソースの要求を達成するために多くのトリッキーな方法を作りました。最も一般的な方法は次のとおりです。

  1. リモートと通信するには、Flash / Silverlightまたはサーバー側を「プロキシ」として使用します。
  2. パディング付きJSON( JSONP
  3. iframeにリモートサーバーを埋め込み、fragmentまたはwindow.nameで通信しherehere参照してhere

これらのトリッキーな方法は多少の問題を抱えています。例えば、JSONPは開発者が単純に "評価"してしまうとセキュリティホールが発生する可能性がありますが、上記の#3では、どちらのドメインも相互に厳密な契約を結ぶ必要があります私見では:)

W3Cは、この問題を解決するための安全で柔軟で推奨される標準的な方法を提供するための標準ソリューションとしてクロスソース・リソース・シェアリング(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

上記の青い部分はkernalファクトで、「Origin」リクエストヘッダは「クロスオリジンリクエストまたはプリフライトリクエストがどこから生じたかを示します」、「Access-Control-Allow-Origin」レスポンスヘッダは、このページがDomainA(値が*の場合、任意のドメインからのリモート要求が許可されます)。

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

OPTIONS DomainB.com/foo.aspx HTTP/1.1

foo.aspxがOPTIONS HTTP verbをサポートしている場合、以下のような応答が返されます。

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リクエストを提出したドメインが含まれている場合のみ、この必須条件ブラウザを満たして、実際のクロスドメイン要求を送信し、 " Preflight-Result-Cache "に保存されます。

私は3年前にCORSについてブログしました: AJAX Cross-Origin HTTPリクエスト


Answer #2

PHPを使用している場合は、PHPファイルのbeaningに以下のコードを追加してみてください:

localhostを使用している場合は、次のようにしてください:

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

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

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

Answer #3

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を許可されたリクエスタドメインとしてリストしているかどうかを確認します。 サイトBがサイトAにこのページにアクセスすることが許可されていることを示していない場合、ブラウザはXMLHttpRequesterrorイベントをトリガーし、要求しているJavaScriptコードへの応答データを拒否します。

単純でないリクエスト

ネットワークレベルで起こることは、上で説明したものよりやや複雑なことがあります。 要求が「単純でない」要求である場合、ブラウザはまずサーバーが要求を受け入れることを検証するために、データなしの「プリフライト」OPTIONS要求を送信します。 リクエストは、どちらか一方(または両方)の場合、単純ではありません。

  • GETまたはPOST以外のHTTP動詞を使用する(例:PUT、DELETE)
  • 非シンプルリクエストヘッダーを使用します。 唯一の単純な要求ヘッダーは次のとおりです。
    • Accept
    • Accept-Language
    • Content-Language
    • Content-Type (これは値がapplication/x-www-form-urlencodedmultipart/form-datatext/plain場合にのみ簡単text/plain

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

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

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の理解」を参照してください。


Answer #4

1.クライアントはhttp:// siteAから原点であるjavascriptコードMyCode.jsをダウンロードします。

ダウンロードを行うコード - あなたのhtmlスクリプトタグまたはxhr(javascriptなど) - http:// siteZから来ています。 また、ブラウザがMyCode.jsを要求すると、OriginA siteAとsiteZ!= siteAにリクエストしていることがわかるため、Origin: http:// siteZというヘッダーが送信されます。 (これを止めることや干渉することはできません。)

2. MyCode.jsの応答ヘッダーには、Access Control-Allow-Origin: http:// siteBが含まれています。これは、MyCode.jsがサイトBへの相互参照を行うことを許可されたと考えていました。

いいえ。 つまり、サイトBだけがこの要求を行うことができます。 したがって、siteZのMyCode.jsへのリクエストでエラーが発生し、通常はブラウザから何も表示されません。 しかし、サーバーでACAO:siteZを返すようにすると、MyCode.jsが表示されます。 あるいは、「*」を送信すると、すべての人が使えるようになります。または、サーバーが常にOrigin:ヘッダーから文字列を送信した場合でも...セキュリティ上、ハッカーを恐れている場合あなたのサーバは、そのような要求をすることが許可されているショートリストの起源のみを許可する必要があります。

それから、MyCode.jsはsiteAから来ます。 siteBへのリクエストを行うと、それらはすべてクロスオリジンであり、ブラウザはOrigin:siteAを送信し、siteBはsiteAを受け取り、許可されたリクエスタの短いリストにあることを認識し、ACAO:siteAを返します。 その時だけ、ブラウザはあなたのスクリプトにそれらの要求の結果を得させます。


Answer #5

クロスオリジン共有の場合、ヘッダー: 'Access-Control-Allow-Origin':'*';

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

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

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


Answer #6

ブラウザがリクエストをブロックするクロスドメインアプリケーションをテストするだけの場合は、安全でないモードでブラウザを開いて、コードを変更せずにコードを安全にすることなくアプリケーションをテストできます。 MAC OSから、これは端末行から行うことができます:

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

Answer #7

私はエクスプレス4とノード7.4と角度で動作し、私はこれを助ける同じ問題を抱えていた:
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 
   });

がんばろう。


Answer #8

質問は少し古すぎて答えることはできませんが、私はこの質問への今後の参照のためにこれを投稿しています。

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

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

http://domain-a.comから提供されるHTMLページは、 <img> srcリクエストでhttp://domain-b.com/image.jpgを作成しhttp://domain-b.com/image.jpg
ウェブ上の多くのページは、今日、別々のドメインからCSSスタイルシート画像スクリプトなどのリソースを読み込みます(したがって、すばらしくすべきです)。

同じ原点のポリシー

セキュリティ上の理由から、ブラウザは、スクリプト内から開始されたクロスオリジンHTTPリクエストを制限します
たとえば、 XMLHttpRequestFetch同じ起点のポリシーに従います。
したがって、 XMLHttpRequestまたはFetchを使用するWebアプリケーションは、 HTTP要求独自のドメインにのみ作成できます

クロスオリジンリソース共有(CORS)

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

Cross-Origin Resource Sharing(CORS)メカニズムは、 クロスドメイン・アクセス制御をWebサーバーに提供し 、クロスドメイン・データの安全な転送を可能にします。
現代のブラウザは、 XMLHttpRequestFetchなどのAPIコンテナで CORSを使用して、クロスオリジンHTTPリクエストのリスクを軽減します。

CORSの仕組み( Access-Control-Allow-Originヘッダー)

Wikipedia

CORS標準では、新しいHTTPヘッダーについて説明しています。このヘッダーは、ブラウザーとサーバーに許可がある場合にのみリモートURLを要求する方法を提供します。

いくつかの検証と承認はサーバーによって実行できますが、 一般的に、これらのヘッダーをサポートし、それらが課す制限を守るのはブラウザーの責任です。

  1. ブラウザは、 Origin HTTPヘッダーとともにOPTIONS要求を送信しOrigin HTTP

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

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

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

    • どの原点サイトが許可されているかを示す応答のACAO( Access-Control-Allow-Origin )ヘッダー。
      例えば:

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

    • サーバーが原点通過要求を許可しない場合のエラーページ

    • すべてのドメインを許可するワイルドカードを使用したACAO( Access-Control-Allow-Origin )ヘッダー:

      Access-Control-Allow-Origin: *





cors