角$ httpでQuandl APIを呼び出しているCORSの問題

私はQuandl（https://www.quandl.com/data/YAHOO/MSFT.json）のWebサイトからデータを取得しようとしています。これは、すべてのブラウザやPostmanのような他のRESTクライアントでもうまく動作します。

私の角型$ http呼び出しはかなり単純に見えますが、ヘッダーの有無にかかわらずかなりの組み合わせを試しました。

$http({ 
     url: 'https://www.quandl.com/data/YAHOO/MSFT.json', 
     method: "GET", 
     headers: { 
      "X-Content-Type-Options": "nosniff", 
      "X-Frame-Options": "SAMEORIGIN", 
      "X-Rack-CORS": "preflight-hit; no-origin" 
     } 
    }) 
    .then(res => { 
     console.log(res); 
    });

標準エラーに https://www.quandl.com/data/YAHOO/MSFT.jsonをロードすることはできません

のXMLHttpRequestを得ます。プリフライトへの応答要求はアクセス制御チェックを通過しません。いいえ要求されたリソースに 'Access-Control-Allow-Origin'ヘッダーが存在します。したがって、オリジン 'http://localhost:2992'は許可されません。応答は、ベンダーがCORS http://help.quandl.com/article/280-does-the-quandl-api-support-cross-origin-resource-sharing-cors

任意のアイデアをサポートしているようだ。しかし、HTTPステータスコード405

を持っていましたか？

ありがとうございました

出典

2016-05-20 user1153896

正しいURLを使用しているかどうか確認しましたか？ Quandlは、そのAPIに異なるURLを提案します。 Quandl - How do I download a dataset using the API

あなたのURLをする必要があります参照してください：https://www.quandl.com/api/v3/datasets/YAHOO/MSFT-MSFT-Microsoft-Corporation.json

出典

2016-05-20 06:54:59 Alexander

アクセス制御 - 許可 - 起源はCORS (Cross-Origin Resource Sharing) headerです。

サイトAがサイトBからコンテンツを取得しようとすると、サイトBは、このページのコンテンツが特定の発信元からアクセス可能であることをブラウザに伝えるために、アクセス制御許可原点応答ヘッダーを送信できます。（原点はドメインであり、スキームとポート番号です。）デフォルトでは、サイトBのページには他の起点からアクセスできません。 Access-Control-Allow-Originヘッダーを使用すると、特定の要求元からのクロスオリジンアクセスの扉が開きます。サイトBがサイトAにアクセスできるように望んでいることを各リソース/ページに対して

、サイトBは、レスポンスヘッダとそのページを提供する必要があります

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

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

非シンプルなリクエスト：ネットワークレベルで何が起こる

は、上述よりも少し複雑になることがあります。リクエストが"non-simple" requestの場合、ブラウザはまずデータなしの「プリフライト」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-または単純ではないヘッダーの場合、ブラウザーは実際の要求を送信します。

サイトAは、アプリケーション/ JSONの非シンプルなContent-Typeの値で、/ somePageのためのPUTリクエストを送信したい、ブラウザが最初のプリフライトリクエストを送信したとすると：

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

について少し詳しくUnderstanding XMLHttpRequest over CORSを参照してください。単純ではない要求。

私は、CORSの問題と解決策をよりよく理解するのに役立つと思います。

出典

2016-05-20 07:07:05

Quandlは、APIを介してデータを要求するときにCORSをサポートします。使用しようとしているURLは、データセットのWebページ用です。代わりにAPI呼び出しを行うには、そのデータセットのQuandlコードを見つけてAPIに渡すだけです。

このページの右上（この場合はYAHOO/MSFT）にQuandlコードがあります。そのため、適切なAPI呼び出しはhttps://www.quandl.com/api/v3/datasets/YAHOO/MSFT.jsonになります。

Quandl APIの操作に関する詳細なドキュメントは、です。

出典

2016-05-21 16:52:33

角$ httpでQuandl APIを呼び出しているCORSの問題

答えて

関連する問題