Postmanにない場合に、JavaScriptコードで「要求されたリソースに「Access-Control-Allow-Origin」ヘッダーがありません」というエラーが表示されるのはなぜですか?

Why does my JavaScript code get a “No 'Access-Control-Allow-Origin' header is present on the requested resource” error when Postman does not?


質問 written by shady sherif @2019-10-27 12:06:00Z

: 2306 : 44 : 3

Flaskに組み込まれたRESTful APIに接続することにより、 JavaScriptを使用して認証を実行しようとしています ただし、リクエストを行うと、次のエラーが表示されます。

XMLHttpRequestはhttp:// myApiUrl / loginをロードできません。 要求されたリソースに「Access-Control-Allow-Origin」ヘッダーがありません。 したがって、Origin 'null'はアクセスを許可されません。

APIまたはリモートリソースがヘッダーを設定する必要があることは知っていますが、Chrome拡張機能Postman経由でリクエストを行ったときになぜ機能したのですか?

これはリクエストコードです:

$.ajax({
    type: "POST",
    dataType: 'text',
    url: api,
    username: 'user',
    password: 'pass',
    crossDomain : true,
    xhrFields: {
        withCredentials: true
    }
})
    .done(function( data ) {
        console.log("done");
    })
    .fail( function(xhr, textStatus, errorThrown) {
        alert(xhr.responseText);
        alert(textStatus);
    });
コメント 1

localhostからリクエストを実行していますか、それとも直接HTMLを実行していますか?

written by MD。 @2013-11-17 19:31:41Z

コメント 2

@ MD.SahibBinMahboobあなたの質問を理解したら、ローカルホストからリクエストをします-私は自分のコンピューターにページを置いて実行します。ホスティングでサイトを展開すると、同じ結果が得られます。

written by ジェダイ氏 @2013-11-17 19:43:54Z

コメント 3

関連性がstackoverflow.com/questions/10143093/…–

written by 高い @2014-07-07 16:39:52Z

コメント 4

もっと読みたい人のために、MDNにはajaxおよびクロスオリジンリクエストに関するすべての良い記事があります: developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

written by Sam Eaton @2015-06-18 15:22:03Z

コメント 5

ノードjsのこのタイプのエラーに関する重要な注意事項。ルートの設定を開始する前に、server.jsファイルの起動時にアクセスヘッダーを設定する必要があります。それ以外の場合、すべてが正常に実行されますが、アプリからリクエストを行うとこのエラーが発生します。

written by アレックスJ @2017-05-09 02:05:10Z

回答 1 written by Peter Mortensen @2014-01-23 00:46:57Z
1255

私がそれを正しく理解していれば、あなたはあなたのページが存在しているのとは異なるドメインに対してXMLHttpRequestをしていることになります。 そのため、通常はセキュリティ上の理由から同じ発信元でリクエストを許可するため、ブラウザはそれをブロックしています。 クロスドメインリクエストを行う場合は、別のことを行う必要があります。 それを達成する方法についてのチュートリアルはCORSの使用です。

郵便配達員を使用している場合、郵便配達員はこのポリシーによって制限されません。 Cross-Origin XMLHttpRequestから引用:

通常のWebページは、XMLHttpRequestオブジェクトを使用してリモートサーバーとデータを送受信できますが、同じオリジンポリシーによって制限されます。 拡張機能はそれほど制限されていません。 拡張機能は、最初にクロスオリジンパーミッションを要求する限り、オリジンの外部のリモートサーバーと通信できます。

コメント 1

あなたが正しい。私のページとは異なるドメインにリクエストを行っています。APIはサーバー上にあり、localhostからリクエストを実行します。回答を受け入れる前に、「リクエストを直接実行する」ことの意味を説明していただけますか?POSTMANはドメインを使用しませんか?

written by ジェダイ氏 @2013-11-17 19:54:44Z

コメント 2

ブラウザはリクエストをブロックしていません。クロスオリジンAjaxリクエストを完全にブロックするブラウザーはIE7以前のみです。IE7以前を除くすべてのブラウザーは、CORS仕様(IE8およびIE9の一部)を実装しています。必要なことは、リクエストに基づいて適切なヘッダーを返すことにより、APIサーバーでCORSリクエストをオプトインすることだけです。mzl.la/VOFrSzでCORSの概念を読んでくださいPostmanもXHR経由でリクエストを送信します。postmanを使用しているときに同じ問題が発生しない場合、これは、知らないうちに同じ要求をpostman経由で送信していないことを意味します。

written by レイニコラス @2013-11-17 20:01:25Z

コメント 3

@ MD.SahibBinMahboob Postmanは、「java / python」コードからリクエストを送信していません。ブラウザから直接リクエストを送信しています。Chrome拡張機能のXHRは、特にクロスオリジンリクエストが関係している場合、動作が少し異なります

written by レイニコラス @2013-11-17 20:08:48Z

コメント 4

@yvesそれは実際にルールを課したのはブラウザです。そのため、ブラウザではなく任意の場所からリクエストを開始すると、ファイルが機能します

written by MD @2015-08-05 12:54:48Z

コメント 5

@ MD.SahibBinMahboob CORSは、エラーがNo 'Access-Control-Allow-Origin' header is present on the requested resource.場合にどのように役立ちますかNo 'Access-Control-Allow-Origin' header is present on the requested resource.

written by スハイルグプタ @2016-02-10 06:42:16Z

回答 2 written by Silvan @2019-11-27 17:16:19Z
523

これは、本番環境やアプリケーションをクライアントに表示する必要がある場合の修正ではありません。UIとバックエンドの開発が異なるサーバー上にあり、本番環境では実際に同じサーバー上にある場合にのみ役立ちます。 たとえば、アプリケーションをローカルでバックエンドサーバーにポイントしてテストする必要がある場合にアプリケーションのUIを開発する場合、このシナリオではこれが完全な修正です。 本番環境の修正では、CORSヘッダーをバックエンドサーバーに追加して、クロスオリジンアクセスを許可する必要があります。

簡単な方法は、Google Chromeに拡張機能を追加するだけで、CORSを使用したアクセスを許可することです。

https://chrome.google.com/webstore/detail/allow-cors-access-control/lhobafahddgcelffkeicbaginigeejlf?hl=en-US

「access-control-allow-origin」ヘッダー要求へのアクセスを許可する場合は、常にこの拡張機能を有効にします。

または

Windowsでは、このコマンドを実行ウィンドウに貼り付けます

chrome.exe --user-data-dir="C:/Chrome dev session" --disable-web-security

これにより、 「access-control-allow-origin」ヘッダー要求へのアクセスを許可する新しいchromeブラウザーが開きます

コメント 1

これはすばらしいことですが、クライアントがこの方法でchromeを起動してWebサービス呼び出しの内部要件を強制することはできません。

written by -Taersious @2015-09-24 17:55:06Z

コメント 2

これは答えとして受け入れられるべきではありません。CORSを理解してアプリを修正するのではなく、サードパーティのプラグインをインストールしてアプリを修正します。他の人はどのようにAPIを使用しますか?それらすべてにこのプラグインをインストールさせますか

written by ジェームズカークビー @2016-04-28 11:10:3​​3Z

コメント 3

この拡張機能をインストールし、リクエストを行いました。フィドラーでリクエストを確認した後、次のように指定されました-> Origin: evil.comこの拡張機能はOriginをevil.comに変更しているようです-wagwanJahMan 16

written by @2016-05-10 12:54:25Z

コメント 4

恒久的な修正が不要な場合、または一時的にCORSを無効にするだけでよい場合、これは本当に素晴らしい答えだと思いますそれが私が必要とするものであり、このソリューションはうまくいきました。明らかに、これは永久的な解決策とは見なされません。

written by jtcotton63 @2017-03-24 00:44:24Z

コメント 5

この答えは結構です。開発作業のために、これにより私はすぐに稼働し、後で適切な修正を見つけるために戻ってきます

written by アダムヒューズ @2017-10-19 19:48:46Z

回答 3 written by Hristiyan Dodov @2017-07-13 18:14:04Z
339

代わりにJSONを処理できる場合は、ドメイン間で話すためにJSONP (末尾のPに注意)を使用してみてください。

$.ajax({
  type: "POST",
  dataType: 'jsonp',
  ...... etc ......

JSONPの操作の詳細については、 こちらをご覧ください

JSONPの出現-本質的に合意に基づいたクロスサイトスクリプティングハック-は、コンテンツの強力なマッシュアップへの扉を開きました。 多くの有名なサイトがJSONPサービスを提供しているため、事前定義されたAPIを介してコンテンツにアクセスできます。

コメント 1

データ型jsonのNodeJとASP.Netが原因で、これが原因でした-Gaizka

written by Allende @2014-05-15 09:36:47Z

コメント 2

jsonpはPOSTコンテンツでは機能しないことに注意してください。その他の議論はこちら

written by プラブラジャ @2014-11-13 00:28:45Z

コメント 3

POSTリクエストでjsonpを使用できない場合、これはどのように多くの賛成票を持っていますか?!?!

written by ファットログ @2015-08-07 15:06:05Z

コメント 4

JSONPを使用する場合、$。ajaxはtypeを無視するため、常にGETあるため、この回答は常に機能します。

written by -noob @2016-10-06 03:56:12Z

コメント 5

また、JSONPはJSONと直接交換できないことに注意してください。サーバーもJSONP形式でデータを返す必要がありますAJAXリクエスト設定のみでdataTypeを変更するだけでは機能しません。

written by ロリーマックロスサン @2017-09-07 10:19:31Z

回答 4 written by shady sherif @2019-07-03 13:32:47Z
219

警告:実稼働環境でこの回答を使用すると、攻撃者を含むURLを持っているユーザーがAPI /サービスを呼び出す可能性があるというセキュリティ上の問題が発生する可能性があります。 この攻撃に対するAPI /サービスを防ぐには、認証にセッションとCookieを使用する必要があります。 API /サービスは、 クロスサイトリクエストフォージェリ (CSRF)に対して脆弱です。

PHPを使用している場合、非常に簡単に解決できます。 リクエストを処理するPHPページの先頭に次のスクリプトを追加するだけです。

<?php header('Access-Control-Allow-Origin: *'); ?>

Node-redを使用している場合は、次の行のコメントを解除して、 node-red/settings.jsファイルでCORSを許可する必要があります。

If you are using Node-red you have to allow CORS in the node-red/settings.js file by un-commenting the following lines:

質問と同じFlaskを使用している場合; あなたは最初にflask-corsをインストールする必要があります

// The following property can be used to configure cross-origin resource sharing
// in the HTTP nodes.
// See https://github.com/troygoode/node-cors#configuration-options for
// details on its contents. The following is a basic permissive set of options:
httpNodeCors: {
 origin: "*",
 methods: "GET,PUT,POST,DELETE"
},

次に、フラスコのcorsをアプリに含めます

If you are using Flask same as the question; you have first to install flask-cors

シンプルなアプリは次のようになります

$ pip install -U flask-cors

詳細については、 フラスコのドキュメントを確認できます

コメント 1

安全ではない

written by -llazzaro 14 @2014-12-20 19:25:19Z

コメント 2

何のためにCORS をオフにしないでくださいこれはひどい答えです。

written by メガー♦14 @2014-12-30 06:12:55Z

コメント 3

安全ではないかもしれませんが、問題はセキュリティに関するものではなく、タスクの実行方法です。これは、クロスドメインAJAXリクエストを処理するときに開発者が選択する必要があるオプションの1つです。問題を解決するのに役立ちました。アプリケーションの場合、データの出所は気にしません。宛先ドメインでPHPを使用してすべての入力をサニタイズします。そのため、誰かがジャンクを投稿したい場合は、試してみましょう。ここでの主なポイントは、クロスドメインAJAXを宛先ドメインから許可できることです。答えは+1。

written by ZurabWeb @2015-02-26 16:37:57Z

コメント 4

Pieroが提供する一般的なメッセージには同意しますが、それは特にセキュリティに関するものではありませんが、セキュリティは懸念事項です。これは少なくとも「これは一般に悪いことです。あなたが何をしているのかわからない限り、これをしないでください。それに関するさらなる文書があります:...」と言ったはずです。誰かがここに来て、「ああ、このヘッダーを追加/調整するだけでいいのです」と思うのは嫌です。そして、完全な影響を知りません。つまり、調査することはすべて彼らにとって一種のことですが、それでもすべてです。

written by トーマスF. @2015-10-15 14:55:13Z

コメント 5

私はこの答えが好きです...私は同じ問題を抱えており、それを解決しています...彼はいくつかのセキュリティ問題があると説明しましたが、それは別の問題であり、誰もが個々にその問題を考えて解決できるようにします...

written by @2017-03-17 19:38:18Z

回答 5 written by yoshyosh @2018-03-09 08:51:44Z
178

誰かがずっと前にhttp://cors.io/でこのサイトを共有してくれたら、自分のプロキシを構築して依存するのに比べて時間を大幅に節約できただろう。 ただし、本番環境に移行するときは、データのすべての側面を引き続き制御できるため、独自のプロキシを持つことが最善策です。

必要なもの:

https://cors.io/?http://HTTP_YOUR_LINK_HERE

コメント 1

これの欠点は何ですか?それらの人は私のデータを傍受していますか?

written by セバスティ @2015-08-21 16:33:45Z

コメント 2

サードパーティのプロキシを介してデータを送信することは良い考えだとは思わない

written by ダニエルアレクサンドロフ @2015-10-16 14:07:01Z

コメント 3

1つの欠点は、現在のように、それらが時々過負荷になることです。This application is temporarily over its serving quota. Please try again later.

written by -evelynhathaway @2016-02-20 07:52:14Z

コメント 4

テストのための黄金!foo.bar.whateverからテストデータを読み込むために長い間苦労してきましたが、これはその問題の解決策です。

written by 自動 @2016-04-18 12:52:55Z

コメント 5

悪い点: The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.い: Apache/2.4.7 (Ubuntu) Server at cors.io Port 80 (このためのApache?LOL)

written by ニノシュコパック @2016-11-01 18:35:40Z

回答 6 written by Peter Mortensen @2016-02-16 23:53:34Z
75

Node.jsを使用している場合は、試してください:

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

詳細: ExpressJSのCORS

コメント 1

これがまさに私が必要とするものだからです。しかし、接続を許可し、本番環境では使用しないことを説明せずに「*」の例を宣伝することは悪い考えだと思います。これは、MDNリンクdeveloper.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORSで説明されています。

written by @2017-06-09 09:12:17Z

コメント 2

@rob、コメントありがとう。そのとおりです。リソースの使用を許可するオリジンを指定する必要があります。しかし、リソースが公共の目的で使用され、消費者がわからない場合は、間違っていない場合は「*」を使用する必要があります。

written by @2017-06-09 11:08:04Z

コメント 3

私はこの概念を使用しており、nodejsで私の問題は解決されています。ありがとう

written by ディーパックバタ @2017-08-20 07:29:42Z

コメント 4

app.use(function(req、res、next){res.setHeader( 'Access-Control-Allow-Origin'、 '*'); res.setHeader( 'Access-Control-Allow-Methods'、 'GET、POST 、OPTIONS、PUT、PATCH、DELETE '); res.setHeader(' Access-Control-Allow-Headers '、' X-Requested-With、content-type、Authorization '); res.setHeader(' Access-Control-Allow -Credentials '、true); if(' OPTIONS '=== req.method){res.send(204);} else {next();}});

written by リッキーシャルマ @2017-09-26 10:05:06Z

コメント 5

"Access-Control-Allow-Origin", "*"を使用する危険性については、 security.stackexchange.com "Access-Control-Allow-Origin", "*"参照してください。tldr: W3仕様は、実際に次のことを推奨しています。アクセス制御チェックなしで、パブリックにアクセスできるリソースは、値が「*」であるAccess-Control-Allow-Originヘッダーを常に安全に返すことができます

written by CODE-REaD @2018-02-15 16:45:58Z

回答 7 written by Alin Razvan @2015-04-02 09:31:50Z
67

Ajaxを使用したクロスドメインの問題があります。 www.なしで同じhttp://パス上のファイルにアクセスしていることを確認する必要がありますwww. (または、 http://www.からアクセスし、 http://www.を含む同じパスに投稿しwww. )ブラウザがwww.経由でアクセスするときに別のドメインと見なしますwww. パスですので、問題がどこにあるかがわかります。 別のドメインに投稿しており、オリジンの問題のためにブラウザがフローをブロックしています。

APIが要求元と同じホストに配置されていない場合、フローはブロックされ、APIと通信する別の方法を見つける必要があります。

コメント 1

うん、私は私のphonegapアプリでこれに強制されました、var app_url = location.protocol + '//' + location.host + '/ api /。問題はwwwのあるサイトでした。先頭に追加するとそのエラーが発生します。

written by サーロジク @2015-04-27 12:26:46Z

回答 8 written by George Livingston @2018-11-13 09:27:03Z
57

なぜなら
$ .ajax({type: "POST" -OPTIONSを呼び出します
$ .post(-POSTを呼び出します

両方とも異なるPostmanは「POST」を適切に呼び出しますが、呼び出すと「OPTIONS」になります

C#Webサービスの場合-webapi

<system.webServer>タグの下のweb.configファイルに次のコードを追加してください。 これは動作します

<httpProtocol>
    <customHeaders>
        <add name="Access-Control-Allow-Origin" value="*" />
    </customHeaders>
</httpProtocol>

ajax呼び出しで間違いをしていないことを確認してください

jQuery

jQuery

Angular 4の問題を参照してください: http : //www.hubfly.com/blog/solutions/how-to-fix-angular-4-api-call-issues/

注: サードパーティのWebサイトからコンテンツをダウンロードする場合、 これは役に立ちません JavaScriptではなく、次のコードを試すことができます。

Angular 4 issue please refer : http://www.hubfly.com/blog/solutions/how-to-fix-angular-4-api-call-issues/

コメント 1

この構成は、Azure ServicesのWordpressで同じエラーを解決しました。ありがとう。

written by アンドレメスキータ @2017-05-22 13:41:53Z

コメント 2

特定のオリジン値を使用して、外部ドメインからのリクエストを回避することをお勧めします。たとえば、 *代わりにhttps://www.myotherdomain.com使用してhttps://www.myotherdomain.com

written by -pechar @2017-06-09 08:30:06Z

回答 9 written by ygormutti @2015-01-09 19:19:59Z
23

XDomainをお試しください

概要:純粋なJavaScript CORSの代替/ポリフィル。 サーバーの設定は不要です-通信したいドメインにproxy.htmlを追加するだけです。 このライブラリはXHookを使用してすべてのXHRをフックするため、XDomainは任意のライブラリと連携して動作するはずです。

回答 10 written by Ganesh Krishnan @2019-01-19 17:54:51Z
12

したくない場合:

  1. Chromeでウェブセキュリティを無効にする
  2. JSONPを使用する
  3. サードパーティのサイトを使用してリクエストを再ルーティングします

サーバーでCORSが有効になっていることを確認します(ここでCORSをテストします: http : //www.test-cors.org/

次に、リクエストでoriginパラメータを渡す必要があります。 このオリジンは、ブラウザがリクエストとともに送信するオリジンと一致する必要があります。

あなたはここで実際にそれを見ることができます: http : //www.wikinomad.com/app/detail/Campgrounds/3591

編集機能は、データを取得するために別のドメインにGET&POSTリクエストを送信します。 問題を解決するoriginパラメーターを設定しました。 バックエンドはmediaWikiエンジンです。

tldr:呼び出しに「origin」パラメーターを追加します。これは、ブラウザーが送信するOriginパラメーターである必要があります(originパラメーターを偽装することはできません)

コメント 1

main.min.jsからのこのサンプルコードを参照していますか?: t.post("https://wiki.wikinomad.com/api.php?origin=https://www.wikinomad.com", n, o).then(function(e) {...その場合、このオリジンを指定する方法では、「バックエンド」から提供されているPHPがそれをサポートするようにコーディングされている必要があり、この答えはそうでなければ動作しますか?

written by コードリード @2018-02-15 20:18:48Z

コメント 2

@ CODE-REaD、はい、バックエンドもCORSをサポートする必要があるのは正しいです。

written by ガネーシュクリシュナン @2019-01-19 17:55:34Z

回答 11 written by Leonid Alzhin @2015-01-29 00:06:05Z
10

AngularJSを使用してAPIにアクセスすると、問題が発生しました。 同じリクエストは、SoapUI 5.0とColdFusionで機能しました。 私のGETメソッドには既にAc​​cess-Control-Allow-Originヘッダーがありました。

AngularJSが「トライアル」のOPTIONSリクエストを行うことがわかりました。 デフォルトでは、ColdFusionはOPTIONSメソッドを生成しますが、これらのヘッダーは特にありません。 エラーは、GETへの意図的な呼び出しではなく、OPTIONS呼び出しへの応答で生成されました。 以下のOPTIONSメソッドをAPIに追加した後、問題は解決しました。

<cffunction name="optionsMethod" access="remote" output="false" returntype="any" httpmethod="OPTIONS" description="Method to respond to AngularJS trial call">
    <cfheader name="Access-Control-Allow-Headers" value="Content-Type,x-requested-with,Authorization,Access-Control-Allow-Origin"> 
    <cfheader name="Access-Control-Allow-Methods" value="GET,OPTIONS">      
    <cfheader name="Access-Control-Allow-Origin" value="*">      
    <cfheader name="Access-Control-Max-Age" value="360">        
</cffunction>
コメント 1

OPTIONSリクエストを行うのは角度ではなく、リクエストに基づいたブラウザです!

written by ナレッツ @2015-10-12 17:36:52Z

コメント 2

Narretz-ブラウザ経由でAPIを呼び出してもこのエラーは発生せず、追加のオプション呼び出しも行われません。アンギュラーが使用されるとき、それはします。

written by レオニードアルジン @2015-11-17 00:20:56Z

コメント 3

Narretzは正しい、それは角度とは関係ありません。これは、CORSの仕組みに関連しています。

written by エミールベルジェロン @2016-10-18 15:23:12Z

回答 12 written by Community @2017-05-23 11:47:32Z
9

shrutiの答えに基づいて、必要な引数を使用してChromeブラウザのショートカットを作成しました: ここに画像の説明を入力してください ここに画像の説明を入力してください

コメント 1

優れた。次に、100,000人のユーザーにアクセスして、ChromeでWebセキュリティを無効にする必要があります。

written by ガネーシュクリシュナン @2016-07-06 06:08:50Z

コメント 2

@GaneshKrishnan質問者は開発者のようで、彼の質問(私の意見では)は、私の問題がそうであったように、開発目的のためのようです。そして、はい、もしあなたがユーザーをハックしたいなら、彼らを、Chromeで彼らのWebセキュリティを無効にしてください:)

written by 巡回し @2016-07-06 18:37:06Z

コメント 3

@GaneshKrishnanこれは、ユーザーの問題に対する許容可能な解決策ではないようです。この修正は開発環境でのみ使用する必要があることに注意してください。

written by セルジオA. @2019-07-05 10:39:29Z

回答 13 written by Peter Mortensen @2017-05-21 10:39:49Z
9

https://github.com/Rob--W/cors-anywhere/は、独自のCORSプロキシをセットアップして実行するために使用できる(Node.js)コードを提供します。 積極的に維持され、正しいAccess-Control-*応答ヘッダーの基本的な送信だけでなく、プロキシの動作を制御するための多くの機能を提供します。

https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORSには、クライアントサイドWebアプリケーションがJavaScriptから作成するクロスオリジンリクエストをブラウザーがどのように処理するか、および送信元を構成する必要があるヘッダーを説明する詳細があります可能な場合、リクエストの送信先サーバー。

リクエストを行い、レスポンスを取得する必要があるサイトがAccess-Control-Allow-Originレスポンスヘッダーを返さない場合、ブラウザは常にクライアントから直接送信されたクロスオリジンリクエストをブロックします-サイドJavaScriptコードが機能しない。 したがって、サイトがあなたが制御するものでなく、動作を設定できる場合、その場合に機能する唯一のことは、リクエストをプロキシすることです。自分で実行する独自のプロキシまたはオープンプロキシを使用します。

ここの他のコメントで述べたように、リクエストでオープンプロキシを信頼しないのには十分な理由があります。 つまり、自分が何をしているのかを知っていて、オープンプロキシがニーズに合っていると判断した場合、 https://cors-anywhere.herokuapp.com/は信頼性が高く、アクティブに維持され、インスタンスを実行しますhttps://github.com/Rob--W/cors-anywhere/コード。

ここで説明した他のオープンプロキシ(少なくともいくつかはもう利用できないようです)と同様に、動作する方法は、クライアントコードに直接http://foo.comリクエストを送信させることですhttp://foo.comhttps://cors-anywhere.herokuapp.com/http://foo.com送信すると、プロキシは必要なAccess-Control-*ヘッダーをブラウザーに表示される応答に追加します。

回答 14 written by Ani Menon @2016-06-28 03:46:53Z
8

サーバーからの応答を要求すると、次の構成があり、同じエラーが発生しました。

サーバー側: SparkJava- > REST-APIを提供します
クライアント側: ExtJs6- >ブラウザーレンダリングを提供

サーバー側では、これを応答に追加する必要がありました。

Spark.get("/someRestCallToSpark", (req, res) -> {
    res.header("Access-Control-Allow-Origin", "*"); //important, otherwise its not working 
    return "some text";
 });

クライアント側では、これをリクエストに追加する必要がありました。

On the client-side I had to add this to the request:

コメント 1

同じアーキテクチャ、したがって同じ問題があり、これがそれを解決しました。

written by ファーフル @2015-10-07 19:03:02Z

コメント 2

これは、任意のドメインからのリクエストを許可するのは得策ではありません。信頼できるドメインのみに制限する必要があります。

written by MD。 @2016-01-15 05:36:50Z

コメント 3

両方のドメインのホストである場合、このタイプのリクエストを有効にすることは一般的な習慣です。

written by kiltek @2016-05-25 08:42:26Z