クロスオリジン読み取りブロッキング（CORB）

Jquery AJAXを使用してサードパーティAPIを呼び出しました。コンソールで次のエラーが発生します：

Cross-Origin Read Blocking（CORB）は、MIMEタイプapplication / jsonのクロスオリジン応答MY URLをブロックしました。詳細については、https：//www.chromestatus.com/feature/5629709824032768を参照してください。

Ajax呼び出しに次のコードを使用しました。

$.ajax({
  type: 'GET',
  url: My Url,
  contentType: 'application/json',
  dataType:'jsonp',
  responseType:'application/json',
  xhrFields: {
    withCredentials: false
  },
  headers: {
    'Access-Control-Allow-Credentials' : true,
    'Access-Control-Allow-Origin':'*',
    'Access-Control-Allow-Methods':'GET',
    'Access-Control-Allow-Headers':'application/json',
  },
  success: function(data) {
    console.log(data);
  },
  error: function(error) {
    console.log("FAIL....=================");
  }
});

Fiddlerでチェックインしたとき、応答としてデータを取得しましたが、Ajax成功メソッドでは取得していません。

私を助けてください。

 dataType:'jsonp',

JSONPリクエストを作成していますが、サーバーはJSONで応答しています。

セキュリティ上のリスクがあるため、ブラウザはJSONをJSONPとして扱うことを拒否しています。（ブラウザーが JSONをJSONPとして処理しようとした場合、せいぜい失敗するだけです）。

参照してくださいこの質問を JSONPが何であるかの詳細については。CORSが利用可能になる前に使用されていたSame Origin Policyを回避するための厄介なハックであることに注意してください。CORSは、この問題に対するよりクリーンで安全で強力なソリューションです。

クロスオリジンリクエストを作成しようとしていると思われ、競合する命令の大量の山に考えられるすべてのものを投げています。

同一生成元ポリシーがどのように機能するかを理解する必要があります。

詳細なガイドについては、この質問を参照してください。

コードに関するいくつかの注意事項：

contentType: 'application/json',

• JSONPを使用する場合、これは無視されます
• GETリクエストを作成しています。タイプを説明するリクエストボディはありません。
• これにより、クロスオリジンリクエストが単純でなくなります。つまり、基本的なCORS権限と同様に、プリフライトも処理する必要があります。

それを削除します。

 dataType:'jsonp',

• サーバーがJSONPで応答していません。

これを削除します。（代わりにサーバーをJSONPで応答させることもできますが、CORSの方が優れています）。

responseType:'application/json',

これはjQuery.ajaxでサポートされているオプションではありません。これを削除します。

xhrFields：{withCredentials：false}、

これがデフォルトです。ajaxSetupでtrueに設定しない限り、これを削除してください。

  headers: {
    'Access-Control-Allow-Credentials' : true,
    'Access-Control-Allow-Origin':'*',
    'Access-Control-Allow-Methods':'GET',
    'Access-Control-Allow-Headers':'application/json',
  },

• これらは応答ヘッダーです。それらは要求ではなく、応答に属します。
• これにより、クロスオリジンリクエストが単純でなくなります。つまり、基本的なCORS権限と同様に、プリフライトも処理する必要があります。

ほとんどの場合、ブロックされた応答はWebページの動作に影響しないはずであり、CORBエラーメッセージは無視しても問題ありません。たとえば、ブロックされた応答の本文がすでに空である場合、または応答を処理できないコンテキスト（404エラーページなどのHTMLドキュメント）に応答が配信される場合に、警告が発生することがあります。タグに配信されます）。

https://www.chromium.org/Home/chromium-security/corb-for-developers

ブラウザのキャッシュを消去する必要がありました。このリンクを読んでいました。リクエストが空のレスポンスを受け取った場合、この警告エラーが発生します。リクエストでいくつかのCORSを取得していたため、このリクエストの応答が空になり、ブラウザのキャッシュをクリアするだけでCORSを取得できました。クロムがPORT番号をキャッシュに保存したため、CORSを受信して​​いました。サーバーが受け入れるだけで、キャッシュのためlocalhost:3010に実行していましたlocalhost:3002。

ヘッダー 'Access-Control-Allow-Origin：*'を含む応答を返します以下のPhpサーバー応答のコードを確認してください。

<?php header('Access-Control-Allow-Origin: *');
header('Content-Type: application/json');
echo json_encode($phparray); 

サーバー側でCORSを追加する必要があります。

nodeJSを使用している場合：

まず、以下のコマンドを使用してインストールする必要があり ますcors。

npm install cors --save

さて、次のコードを追加します（のようなアプリの起動ファイルへapp.js or server.js）

var express = require('express');
var app = express();

var cors = require('cors');
var bodyParser = require('body-parser');

//enables cors
app.use(cors({
  'allowedHeaders': ['sessionId', 'Content-Type'],
  'exposedHeaders': ['sessionId'],
  'origin': '*',
  'methods': 'GET,HEAD,PUT,PATCH,POST,DELETE',
  'preflightContinue': false
}));

require('./router/index')(app);

質問からは明らかではありませんが、これが開発またはテストクライアントで起こっていることであると想定し、すでにFiddlerを使用している場合、Fiddlerに許可応答で応答させることができます。

• Fiddlerで問題のリクエストを選択します
• AutoResponderタブを開く
• Add Ruleルールをクリックして編集します。
  • ここにメソッド：OPTIONS サーバーのURL、例えばMethod:OPTIONS http://localhost
  • *CORSPreflightAllow
• 小切手 Unmatched requests passthrough
• 小切手 Enable Rules

いくつかのメモ：

1. 明らかに、これはAPIサービスを変更することが不可能/実用的でない開発/テストのためのソリューションにすぎません
2. サードパーティのAPIプロバイダーとの契約がこれを許可していることを確認してください
3. 他の人が指摘したように、これはCORSの動作の一部であり、最終的にはヘッダーをAPIサーバーで設定する必要があります。そのサーバーを制御している場合は、自分でヘッダーを設定できます。この場合、それはサードパーティのサービスであるため、発信元サイトのURLを提供できるメカニズムがいくつかあるだけであり、適切なヘッダーで応答するようにサービスを更新します。

localhostで作業している場合は、これを試してください。これは、私にとって有効な唯一の拡張機能とメソッドです（Angular、javascriptのみ、phpなし）。

https://chrome.google.com/webstore/detail/moesif-orign-cors-changer/digfbfaphojjndkpccljibejjbppifbc/related?hl=en

dataTypeあなたのajaxリクエストのをからjsonpに変更してみましたjsonか？それは私の場合それを修正しました。

Chrome拡張機能では、

chrome.webRequest.onHeadersReceived.addListener

サーバーの応答ヘッダーを書き換えます。既存のヘッダーを置き換えるか、追加のヘッダーを追加できます。これはあなたが望むヘッダーです：

Access-Control-Allow-Origin: *

https://developers.chrome.com/extensions/webRequest#event-onHeadersReceived

CORBの問題に悩まされ、これで修正されました。

応答ヘッダーは通常、サーバーで設定されます。設定する'Access-Control-Allow-Headers'には'Content-Type'、サーバー側で

Cross-Origin Read Blocking（CORB）は、疑わしいクロスオリジンリソースロードが、Webページに到達する前にWebブラウザーによって識別およびブロックされるアルゴリズムです。これは、ブラウザーが特定のクロスオリジンネットワークレスポンスを送信しないように設計されています。ウェブページへ。

まず、これらのリソースが正しい「Content-Type」で提供されていることを確認します。つまり、JSON MIMEタイプ-" text/json"、 " application/json"、HTML MIMEタイプ-" text/html"の場合です。

2番目：モードをcorsに設定します。 mode:cors

フェッチは次のようになります

 fetch("https://example.com/api/request", {
            method: 'POST',
            body: JSON.stringify(data),
            mode: 'cors',
            headers: {
                'Content-Type': 'application/json',
                "Accept": 'application/json',
            }
        })
    .then((data) => data.json())
    .then((resp) => console.log(resp))
    .catch((err) => console.log(err))

参照：https : //chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md

https://www.chromium.org/Home/chromium-security/corb-for-developers

このコンテキストで言及する価値のあるエッジケースがあります。Chrome（少なくとも一部のバージョン） は、CORBに設定されたアルゴリズムを使用してCORSプリフライトをチェックします。IMO、プリフライトはCORB脅威モデルに影響を与えず、CORBはCORSと直交するように設計されているため、これは少しばかげています。また、CORSプリフライトの本文にはアクセスできないため、苛立たしい警告だけで悪影響はありません。

とにかく、CORSプリフライト応答（OPTIONSメソッド応答）に本文がない（204）ことを確認してください。コンテンツタイプapplication / octet-streamと長さ0の空の200もここではうまく機能しました。

これが当てはまるかどうかを確認するには、メッセージ本文でCORB警告とOPTIONS応答をカウントします。

この警告は、200の空の応答を送信したときに発生したようです。

私のこの設定では、.htaccessChromeで警告が表示されます。

Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Methods "POST,GET,HEAD,OPTIONS,PUT,DELETE"
Header always set Access-Control-Allow-Headers "Access-Control-Allow-Headers, Origin,Accept, X-Requested-With, Content-Type, Access-Control-Request-Method, Access-Control-Request-Headers, Authorization"

RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule .* / [R=200,L]

しかし最後の行を

RewriteRule .* / [R=204,L]

問題を解決してください！

Chrome拡張機能にも同じ問題がありました。私のマニフェストの「content_scripts」オプションにこの部分を追加しようとしたとき：

//{
    //  "matches": [ "<all_urls>" ],
    //  "css": [ "myStyles.css" ],
    //  "js": [ "test.js" ]
    //}

そして、私は私のマニフェスト「許可」から他の部分を削除します：

"https://*/"

XHR要求の1つでCORBを削除した場合のみ、表示されなくなります。

最悪の場合、コードにXHR要求がほとんどなく、そのうちの1つだけがCORBエラーを受け取り始めます（なぜCORBが他のXHRに当てはまらないのか、わからない。マニフェストの変更がこのエラーを引き起こした理由はわからない）。そのため、コード全体を数時間で何度も検査し、多くの時間を失いました。

Safariでそれを行う場合は時間がかかりません。[設定] >> [プライバシー]から開発者メニューを有効にし、開発メニューから[クロスオリジン制限を無効にする]をオフにします。ローカルのみが必要な場合は、開発者メニューを有効にし、開発メニューから[ローカルファイル制限を無効にする]を選択するだけです。

Chrome for OSXでターミナルを開いて実行：

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

--OSX上のChrome 49以降ではuser-data-dirが必要

Linuxの場合：

$ google-chrome --disable-web-security

また、AJAXやJSONなどの開発目的でローカルファイルにアクセスしようとしている場合も、このフラグを使用できます。

-–allow-file-access-from-files

Windowsの場合は、コマンドプロンプトに移動し、Chrome.exeがあるフォルダーに移動して、次のように入力します。

chrome.exe --disable-web-security

これにより、同じ生成元ポリシーが無効になり、ローカルファイルにアクセスできるようになります。

サーバーからのjsonp応答の形式が間違っているため、この問題が発生しました。不正な応答は次のとおりです。

callback(["apple", "peach"])

問題は、内部のオブジェクトがcallbackjson配列ではなく、正しいjsonオブジェクトであることです。だから私はいくつかのサーバーコードを変更し、そのフォーマットを変更しました：

callback({"fruit": ["apple", "peach"]})

ブラウザは変更後の応答を喜んで受け入れました。

Google Chromeで問題が発生している場合は、「Moesif CORS」拡張機能をインストールしてみてください。クロスオリジンリクエストであるため、応答ステータスコードが200であっても、Chromeは応答を受け入れません。