Cross-Origin Read Blocking (CORB)

Ho chiamato API di terze parti utilizzando Jquery AJAX. Ricevo il seguente errore nella console:

Cross-Origin Read Blocking (CORB) ha bloccato la risposta cross-origin MY URL con tipo / applicazione MIME / json. Vedi https://www.chromestatus.com/feature/5629709824032768 per maggiori dettagli.

Ho usato il seguente codice per la chiamata 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....=================");
  }
});

Quando ho registrato Fiddler, ho i dati in risposta ma non nel metodo di successo Ajax.

Per favore aiutatemi.

 dataType:'jsonp',

Stai effettuando una richiesta JSONP, ma il server risponde con JSON.

Il browser si rifiuta di provare a trattare JSON come JSONP perché sarebbe un rischio per la sicurezza. (Se il browser lo ha fatto cercare di trattare il JSON come JSONP allora sarebbe, nella migliore delle ipotesi, fallire).

Vedi questa domanda per maggiori dettagli su cos'è JSONP. Si noti che è un brutto trucco per aggirare la stessa politica di origine utilizzata prima che fosse disponibile CORS. CORS è una soluzione molto più pulita, più sicura e più potente al problema.

Sembra che tu stia provando a fare una richiesta di origine incrociata e stai lanciando tutto ciò che ti viene in mente in un enorme mucchio di istruzioni contrastanti.

Devi capire come funziona la politica della stessa origine.

Vedi questa domanda per una guida approfondita.

Ora alcune note sul tuo codice:

contentType: 'application/json',

• Questo viene ignorato quando si utilizza JSONP
• Stai effettuando una richiesta GET. Non esiste un corpo di richiesta per descrivere il tipo di.
• Ciò renderà non semplice una richiesta di origine incrociata, il che significa che, oltre alle autorizzazioni CORS di base, è necessario anche gestire un pre-volo.

Rimuovi quello.

 dataType:'jsonp',

• Il server non risponde con JSONP.

Rimuovilo. (È possibile invece fare in modo che il server risponda con JSONP, ma CORS è migliore).

responseType:'application/json',

Questa non è un'opzione supportata da jQuery.ajax. Rimuovilo.

xhrFields: {withCredentials: false},

Questo è il valore predefinito. A meno che non lo si imposta su true con ajaxSetup, rimuoverlo.

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

• Queste sono le intestazioni di risposta. Appartengono alla risposta, non alla richiesta.
• Ciò renderà non semplice una richiesta di origine incrociata, il che significa che, oltre alle autorizzazioni CORS di base, è necessario anche gestire un pre-volo.

Nella maggior parte dei casi, la risposta bloccata non dovrebbe influire sul comportamento della pagina Web e il messaggio di errore CORB può essere ignorato in modo sicuro. Ad esempio, l'avviso può verificarsi nei casi in cui il corpo della risposta bloccata era già vuoto o quando la risposta stava per essere recapitata in un contesto che non è in grado di gestirla (ad esempio, un documento HTML come una pagina di errore 404 essere consegnato a un tag).

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

Ho dovuto pulire la cache del mio browser, leggevo in questo link che, se la richiesta riceve una risposta vuota, viene visualizzato questo errore di avviso. Stavo ricevendo alcuni CORS sulla mia richiesta, e quindi la risposta di questa richiesta è stata vuota, tutto quello che dovevo fare era svuotare la cache del browser e CORS è andato via. Stavo ricevendo CORS perché Chrome aveva salvato il numero PORT nella cache, il server avrebbe semplicemente accettato localhost:3010e lo stavo facendo localhost:3002, a causa della cache.

Restituisci la risposta con l'intestazione "Access-Control-Allow-Origin: *" Controlla sotto il codice per la risposta del server Php.

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

Devi aggiungere CORS sul lato server:

Se si utilizza nodeJS, allora:

Innanzitutto è necessario installare cors utilizzando il comando seguente:

npm install cors --save

Ora aggiungi il seguente codice al tuo file di avvio dell'app come ( 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);

Non è chiaro dalla domanda, ma supponendo che ciò accada su un client di sviluppo o test e dato che stai già utilizzando Fiddler puoi far rispondere Fiddler con una risposta consentita:

• Seleziona la richiesta del problema in Fiddler
• Apri il AutoResponder scheda
• Clic Add Rule e modifica la regola per:
  • Metodo: URL del server OPTIONS qui , ad esMethod:OPTIONS http://localhost
  • *CORSPreflightAllow
• Dai un'occhiata Unmatched requests passthrough
• Dai un'occhiata Enable Rules

Un paio di note:

1. Ovviamente questa è solo una soluzione per sviluppo / test in cui non è possibile / pratico modificare il servizio API
2. Verifica che eventuali accordi con il fornitore dell'API di terze parti ti consentano di farlo
3. Come altri hanno notato, questo fa parte del modo in cui CORS funziona e alla fine sarà necessario impostare l'intestazione sul server API. Se controlli quel server, puoi impostare tu stesso le intestazioni. In questo caso, poiché si tratta di un servizio di terze parti, posso solo supporre che dispongano di un meccanismo attraverso il quale sei in grado di fornire loro l'URL del sito di origine e aggiorneranno il loro servizio di conseguenza per rispondere con le intestazioni corrette.

Se stai lavorando su localhost, prova questo, questo è l'unica estensione e metodo che ha funzionato per me (angolare, solo javascript, no php)

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

hai provato a cambiare il dataTypenella tua richiesta Ajax da jsonpa json? nel mio caso è stato risolto.

In un'estensione di Chrome, puoi usare

chrome.webRequest.onHeadersReceived.addListener

per riscrivere le intestazioni di risposta del server. È possibile sostituire un'intestazione esistente o aggiungere un'intestazione aggiuntiva. Questa è l'intestazione che vuoi:

Access-Control-Allow-Origin: *

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

Ero bloccato su problemi CORB, e questo mi ha risolto il problema.

Le intestazioni di risposta sono generalmente impostate sul server. Situato 'Access-Control-Allow-Headers'a 'Content-Type'sul lato server

Cross-Origin Read Blocking (CORB), un algoritmo attraverso il quale i carichi di risorse tra le origini sospette possono essere identificati e bloccati dai browser Web prima che raggiungano la pagina Web. È progettato per impedire al browser di fornire determinate risposte di rete tra origini a una pagina Web.

Prima di tutto assicurati che queste risorse siano fornite con un " Content-Type" corretto , cioè per il tipo MIME JSON - " text/json", " application/json", tipo MIME HTML - " text/html".

Secondo: imposta la modalità su cors, ovvero mode:cors

Il recupero sarebbe simile a questo

 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))

riferimenti: 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

C'è un caso limite degno di nota in questo contesto: Chrome (alcune versioni, almeno) controlla i preflight CORS usando l'algoritmo impostato per CORB . IMO, questo è un po 'sciocco perché i preflight non sembrano influenzare il modello di minaccia CORB e CORB sembra progettato per essere ortogonale a CORS. Inoltre, il corpo di un preflight CORS non è accessibile, quindi non ci sono conseguenze negative solo un avviso irritante.

In ogni caso, verifica che le risposte di verifica preliminare CORS (risposte al metodo OPTIONS) non abbiano un corpo (204) . Anche qui un 200 vuoto con tipo di contenuto application / octet-stream e lunghezza zero ha funzionato bene.

Puoi confermare se questo è il caso che stai colpendo contando gli avvisi CORB e le OPZIONI con un messaggio.

Sembra che questo avviso si sia verificato durante l'invio di una risposta vuota con un 200.

Questa configurazione nel mio .htaccessdisplay l'avviso su Chrome:

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]

Ma cambiando l'ultima riga in

RewriteRule .* / [R=204,L]

risolvere il problema!

Ho avuto lo stesso problema con la mia estensione Chrome. Quando ho provato ad aggiungere all'opzione manifest "content_scripts" questa parte:

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

E rimuovo l'altra parte dai miei "permissons" manifesti:

"https://*/"

Solo quando lo elimino CORB su una delle mie richieste XHR scompare.

Peggio di tutto, ci sono poche richieste XHR nel mio codice e solo una di esse inizia a ottenere l'errore CORB (non so perché CORB non appare su altri XHR; perché i cambiamenti manifest hanno causato questo errore non lo so). Ecco perché ho ispezionato l'intero codice ancora e ancora per poche ore e ho perso molto tempo.

Se lo fai in Safari non ci vuole tempo, basta abilitare il menu sviluppatore da Preferenze >> Privacy e deselezionare "Disabilita Restrizioni Cross-Origin" dal menu Sviluppo. Se desideri solo locali, devi solo abilitare il menu sviluppatore e selezionare "Disabilita restrizioni file locali" dal menu Sviluppo.

e in Chrome per OSX aprire Terminale ed eseguire:

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

--utente-data-dir richiesto su Chrome 49+ su OSX

Per Linux eseguire:

$ google-chrome --disable-web-security

Inoltre, se stai provando ad accedere ai file locali per scopi di sviluppo come AJAX o JSON, puoi usare anche questo flag.

-–allow-file-access-from-files

Per Windows vai al prompt dei comandi e vai nella cartella in cui è Chrome.exe e digita

chrome.exe --disable-web-security

Ciò dovrebbe disabilitare la stessa politica di origine e consentire di accedere ai file locali.

Ho riscontrato questo problema perché il formato della risposta jsonp dal server è errato. La risposta errata è la seguente.

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

Il problema è che l'oggetto all'interno callbackdovrebbe essere un oggetto json corretto, anziché un array json. Quindi ho modificato un po 'di codice del server e ho cambiato il suo formato:

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

Il browser ha accettato felicemente la risposta dopo la modifica.

Prova a installare l'estensione "Moesif CORS" se stai riscontrando problemi in Google Chrome. Poiché si tratta di una richiesta di origine incrociata, Chrome non accetta una risposta anche quando il codice di stato della risposta è 200