Bloqueo de lectura de origen cruzado (CORB)

130

He llamado a API de terceros usando Jquery AJAX. Recibo el siguiente error en la consola:

El bloqueo de lectura de origen cruzado (CORB) bloqueó la respuesta de origen cruzado MY URL con el tipo MIME application / json. Consulte https://www.chromestatus.com/feature/5629709824032768 para obtener más detalles.

He usado el siguiente código para la llamada 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....=================");
  }
});

Cuando revisé en Fiddler, obtuve los datos en respuesta pero no en el método de éxito de Ajax.

Por favor, ayúdame.

Jignesh
fuente
3
Parece que la API a la que está llamando no ha habilitado los encabezados necesarios para permitir llamadas entre dominios desde JS. Lo más probable es que necesites hacer la llamada en el servidor. ¿Estás seguro de que la respuesta es JSONP y no JSON simple? También tenga en cuenta que los encabezados que está agregando en la solicitud deben colocarse en la respuesta del servidor.
Rory McCrossan
3
¿Has resuelto este error o advertencia de CORB? Estoy experimentando lo mismo con el módulo de solicitud.
Sherwin Ablaña Dapito
3
@ SherwinAblañaDapito si todavía está buscando una solución, vea mi respuesta para entornos de desarrollo / prueba
Colin Young
1
Para demostrar cómo su JS puede funcionar correctamente, puede iniciar Chrome en un modo inseguro chrome.exe --user-data-dir = "C: / Chrome dev session" --disable-web-security But "Read Blocking (CORB) respuesta de origen cruzado bloqueado " debe corregirse en el lado del servidor.
Ruslan Novikov

Respuestas:

37
 dataType:'jsonp',

Está realizando una solicitud JSONP, pero el servidor responde con JSON.

El navegador se niega a tratar de tratar el JSON como JSONP porque sería un riesgo de seguridad. (Si el navegador se trata de tratar el JSON como JSONP entonces sería, en el mejor de falla).

Consulte esta pregunta para obtener más detalles sobre qué es JSONP. Tenga en cuenta que es un truco desagradable para evitar la misma política de origen que se utilizó antes de que CORS estuviera disponible. CORS es una solución al problema mucho más limpia, segura y potente.


Parece que está tratando de hacer una solicitud de origen cruzado y está lanzando todo lo que se le ocurre en una enorme pila de instrucciones contradictorias.

Debe comprender cómo funciona la política del mismo origen.

Consulte esta pregunta para obtener una guía detallada.


Ahora algunas notas sobre su código:

contentType: 'application/json',
  • Esto se ignora cuando usa JSONP
  • Estás haciendo una solicitud GET. No hay un cuerpo de solicitud para describir el tipo de.
  • Esto hará que una solicitud de origen cruzado no sea simple, lo que significa que, además de los permisos básicos de CORS, también debe lidiar con un vuelo previo.

Eliminar eso.

 dataType:'jsonp',
  • El servidor no responde con JSONP.

Quita esto. (Puede hacer que el servidor responda con JSONP, pero CORS es mejor).

responseType:'application/json',

Esta no es una opción compatible con jQuery.ajax. Quita esto.

xhrFields: {withCredentials: false},

Este es el valor predeterminado. A menos que lo esté configurando en verdadero con ajaxSetup, elimine esto.

  headers: {
    'Access-Control-Allow-Credentials' : true,
    'Access-Control-Allow-Origin':'*',
    'Access-Control-Allow-Methods':'GET',
    'Access-Control-Allow-Headers':'application/json',
  },
  • Estos son encabezados de respuesta. Pertenecen a la respuesta, no a la solicitud.
  • Esto hará que una solicitud de origen cruzado no sea simple, lo que significa que, además de los permisos básicos de CORS, también debe lidiar con un vuelo previo.
Quentin
fuente
20

En la mayoría de los casos, la respuesta bloqueada no debería afectar el comportamiento de la página web y el mensaje de error CORB puede ignorarse de manera segura. Por ejemplo, la advertencia puede ocurrir en los casos en que el cuerpo de la respuesta bloqueada ya estaba vacía, o cuando la respuesta se entregaría a un contexto que no puede manejarlo (por ejemplo, un documento HTML como una página de error 404 ser entregado a una etiqueta).

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

Tuve que limpiar el caché de mi navegador, estaba leyendo en este enlace que, si la solicitud obtiene una respuesta vacía, recibimos este error de advertencia. Estaba recibiendo algo de CORS en mi solicitud, por lo que la respuesta de esta solicitud se quedó vacía. Todo lo que tenía que hacer era borrar el caché del navegador y CORS se escapó. Estaba recibiendo CORS porque el cromo había guardado el número de PUERTO en la memoria caché. El servidor simplemente aceptaría localhost:3010y lo estaba haciendo localhost:3002debido a la memoria caché.

Alex
fuente
12

Respuesta de respuesta con el encabezado 'Access-Control-Allow-Origin: *' Verifique el siguiente código para la respuesta del servidor Php.

<?php header('Access-Control-Allow-Origin: *');
header('Content-Type: application/json');
echo json_encode($phparray); 
Jestin
fuente
2
Su respuesta me ayudó MUCHO !!! Simplemente no puedo agradecerte lo suficiente. Continuaré investigando lo que hace "Access Control Allow Origin", así que entiendo las ramificaciones, pero estoy aprendiendo lo básico para crear un servicio web PHP y esto me ayudó como si no creyeras. ¡¡¡GRACIAS!!!
Adam Laurie
Esto no soluciona el problema en absoluto. Es un error CORB causado por enviar una respuesta Content-Type: application/jsondentro. El código del OP ya debe estar haciendo esto.
Quentin
1
@Quentin, ??? El sentido común establece que, siempre que tenga Permitir origen, el navegador permitirá la solicitud independientemente de cualquier encabezado / cuerpo sospechoso.
Pacerier
7

Tienes que agregar CORS en el lado del servidor:

Si está utilizando nodeJS, entonces:

Primero necesitas instalar cors usando el siguiente comando:

npm install cors --save

Ahora agregue el siguiente código al archivo de inicio de su aplicación como ( 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);
Shubham Verma
fuente
22
Si necesita agregar una extensión para solucionar su problema, está manejando incorrectamente la solicitud del lado del servidor. Solo una nota.
Alexander Falk
2
No es factible pedir que mi base de usuarios instale una extraña extensión de Chrome. ¿Qué pasa con otros navegadores?
Israel Rodríguez
2
Si bien esta respuesta no resuelve el problema a largo plazo, estaba usando este complemento que verificó a mis compañeros de trabajo que era un problema de CORS. ¡Tan votado por eso!
KoldBane
2
@VladimirNul, la respuesta original era sobre una extensión de Chrome. Shubham lo reescribió. Verifique el historial por favor.
Israel Rodríguez
3
Hay cierta confusión aquí. El OP se refiere a CORB y no a CORS.
No es una máquina
3

La pregunta no lo aclara, pero suponiendo que esto ocurra en un cliente de desarrollo o prueba, y dado que ya está utilizando Fiddler, puede hacer que Fiddler responda con una respuesta permitida:

  • Seleccione la solicitud de problema en Fiddler
  • Abre la AutoResponderpestaña
  • Haga clic Add Ruley edite la regla para:
    • Método: URL del servidor OPTIONS aquí , p. Ej.Method:OPTIONS http://localhost
    • *CORSPreflightAllow
  • Cheque Unmatched requests passthrough
  • Cheque Enable Rules

Un par de notas:

  1. Obviamente, esta es solo una solución para el desarrollo / prueba donde no es posible / práctico modificar el servicio API
  2. Verifique que cualquier acuerdo que tenga con el proveedor de API de terceros le permita hacer esto
  3. Como otros han señalado, esto es parte de cómo funciona CORS, y eventualmente el encabezado deberá configurarse en el servidor API. Si controla ese servidor, puede configurar los encabezados usted mismo. En este caso, dado que es un servicio de terceros, solo puedo suponer que tienen algún mecanismo a través del cual puede proporcionarles la URL del sitio de origen y actualizarán su servicio en consecuencia para responder con los encabezados correctos.
Colin Young
fuente
2

¿ha intentado cambiar el dataTypeen su solicitud ajax de jsonpa json? eso lo solucionó en mi caso.

Cla
fuente
2

En una extensión de Chrome, puede usar

chrome.webRequest.onHeadersReceived.addListener

para reescribir los encabezados de respuesta del servidor. Puede reemplazar un encabezado existente o agregar un encabezado adicional. Este es el encabezado que desea:

Access-Control-Allow-Origin: *

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

Estaba atrapado en problemas de CORB, y esto me lo solucionó.

paso a paso
fuente
1
"A partir de Chrome 72, si necesita modificar las respuestas antes de que Cross Origin Read Blocking (CORB) pueda bloquear la respuesta, debe especificar 'extraHeaders' en opt_extraInfpSpec". del documento webRequests
swisswiss
0

Los encabezados de respuesta generalmente se configuran en el servidor. Establecer 'Access-Control-Allow-Headers'en 'Content-Type'el lado del servidor

LifetimeLearner007
fuente
77
Estoy usando API de terceros. Entonces no puedo hacer eso. Por favor, dame cualquier solución del lado del cliente.
Jignesh
44
El servidor decide qué permitir y qué no. Solo el servidor tiene ese acceso. Controlar los encabezados de respuesta desde el lado del cliente es un riesgo de seguridad. El trabajo del lado del cliente es enviar una solicitud adecuada y luego obtener cualquier respuesta enviada por el servidor. Vea esto: stackoverflow.com/questions/17989951/…
lifetimeLearner007
48
Esto es CORB, no CORS.
Joaquin Brandan
0

Cross-Origin Read Blocking (CORB), un algoritmo por el cual los navegadores web pueden identificar y bloquear cargas dudosas de recursos de origen cruzado antes de que lleguen a la página web ... Está diseñado para evitar que el navegador entregue ciertas respuestas de red de origen cruzado a una página web.

Primero, asegúrese de que estos recursos se sirvan con un " Content-Type" correcto , es decir, para el tipo MIME JSON - " text/json", " application/json", tipo MIME HTML - " text/html".

Segundo: establecer el modo en cors, es decir, mode:cors

La búsqueda se vería así

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

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

Nikil Munireddy
fuente
0

Hay un caso extremo que vale la pena mencionar en este contexto: Chrome (algunas versiones, al menos) verifica las comprobaciones previas de CORS utilizando el algoritmo configurado para CORB . En mi opinión, esto es un poco tonto porque las comprobaciones previas no parecen afectar el modelo de amenaza CORB, y CORB parece estar diseñado para ser ortogonal a CORS. Además, el cuerpo de una verificación previa CORS no es accesible, por lo que no hay consecuencias negativas, solo una advertencia irritante.

De todos modos, verifique que sus respuestas de verificación previa CORS (respuestas del método OPTIONS) no tengan un cuerpo (204) . Un 200 vacío con tipo de contenido application / octet-stream y longitud cero también funcionó bien aquí.

Puede confirmar si este es el caso que está recibiendo contando las advertencias CORB frente a las respuestas OPTIONS con un cuerpo de mensaje.

Simon Thum
fuente
0

Parece que esta advertencia se produjo al enviar una respuesta vacía con un 200.

Esta configuración en mi .htaccesspantalla muestra la advertencia en 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]

Pero cambiando la última línea a

RewriteRule .* / [R=204,L]

¡Resuelve este problema!

fluminis
fuente
-2

Tuve el mismo problema con mi extensión de Chrome. Cuando intenté agregar a mi opción de manifiesto "content_scripts" esta parte:

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

Y elimino la otra parte de mis "permisos" manifiestos:

"https://*/"

Solo cuando lo elimino CORB en una de mis solicitudes XHR desaparece.

Lo peor de todo es que hay pocas solicitudes XHR en mi código y solo una de ellas comienza a recibir un error CORB (no sé por qué CORB no aparece en otro XHR; no sé por qué los cambios manifiestos provocaron este error). Es por eso que inspeccioné todo el código una y otra vez por unas pocas horas y perdí mucho tiempo.

Олег Хитрень
fuente
Hubo algún problema con los encabezados en el lado del servidor. Cambio mi valor de retorno de ASP.NET a: public async Task <string> Get (string TM) El valor de retorno fue hace un momento JSON (tipo de contenido, supongo "application / json") y ahora es el otro (puede ser "texto /llanura"). Y eso ayuda. Ahora devuelvo "permisos" manifiestos a "https: // * /" y funciona.
Олег Хитрень
-3

Si lo hace en un safari, no toma tiempo, simplemente habilite el menú de desarrollador en Preferencias >> Privacidad y anule la selección de "Desactivar restricciones de origen cruzado" en el menú de desarrollo. Si solo quiere local, entonces solo necesita habilitar el menú de desarrollador y seleccionar "Deshabilitar restricciones de archivos locales" en el menú de desarrollo.

y en Chrome para OSX, abra la Terminal y ejecute:

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

- se requiere directorio de datos de usuario en Chrome 49+ en OSX

Para ejecutar Linux:

$ google-chrome --disable-web-security

Además, si está intentando acceder a archivos locales para fines de desarrollo como AJAX o JSON, también puede usar este indicador.

-–allow-file-access-from-files

Para Windows, vaya al símbolo del sistema, vaya a la carpeta donde está Chrome.exe y escriba

chrome.exe --disable-web-security

Eso debería deshabilitar la misma política de origen y permitirle acceder a archivos locales.

Muhammad Haris Baig
fuente
-3

Encontré este problema porque el formato de la respuesta jsonp del servidor es incorrecto. La respuesta incorrecta es la siguiente.

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

El problema es que el objeto dentro callbackdebe ser un objeto json correcto, en lugar de una matriz json. Así que modifiqué un código de servidor y cambié su formato:

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

El navegador aceptó felizmente la respuesta después de la modificación.

Searene
fuente
callback(["apple", "peach"])es perfectamente válido JSONP, y funcionó bien cuando lo probé en todos los orígenes.
Quentin
-4

Intenta instalar la extensión "Moesif CORS" si tienes problemas con Google Chrome. Como es una solicitud de origen cruzado, Chrome no acepta una respuesta incluso cuando el código de estado de la respuesta es 200

Madhurish Gupta
fuente