symfony3 - CORS con Symfony, jQuery, FOSRestBundle y NelmioCorsBundle

reason cors header access control allow origin missing symfony

Question

⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
TL; DR: Editar (antes de leer todo):

Este problema está resuelto porque cometí un error muy estúpido en mi código, no relacionado con CORS ni nada.
Si desea leer este tema de todos modos, solo tenga en cuenta que tiene una configuración de CORS que funciona , si es posible que desee tomar un buen ejemplo.

⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️

_{(fin de la nota)}

Situación

Tengo una aplicación Symfony multidominio, y la parte de back-end actualiza datos con servicios web, no formularios clásicos, por alguna razón.

Back-end: back.mydomain.dev Webservices domain: api.mydomain.dev

Estoy usando jQuery para hacer llamadas AJAX a estos servicios web, y si quiero modificar o crear objetos, también envío solicitudes AJAX, los objetos se fusionan con entidades de Doctrine y persisten.

He estado luchando durante todo un año para hacer solicitudes GET, PUT, POST y DELETE que funcionen correctamente en esta aplicación, y solo porque están en dominios diferentes, me veo obligado a configurar CORS en mis diferentes entornos.

Preparar

Todas las solicitudes de jQuery AJAX se ven así:

ajaxObject = {
    url: ''http://api.mydomain.dev/'' + uri,
    type: method, // Can be GET, PUT, POST or DELETE only
    dataType: ''json'',
    xhrFields: {
         withCredentials: true
    },
    crossDomain: true,
    contentType: "application/json",
    jsonp: false,
    data: method === ''GET'' ? data : JSON.stringify(data) // Here, "data" is ALWAYS containing a plain object. If empty, it equals to "{}"
};

// ... Add callbacks depending on requests

$.ajax(ajaxObject);

Detrás, las rutas se administran con Symfony.

Para la configuración de CORS , estoy usando NelmioCorsBundle con esta configuración:

nelmio_cors:
    paths:
       "^/":
          allow_credentials: true
          origin_regex: true
          allow_origin:
              - "^(https?://)?(back|api)/.mydomain.dev/?"
          allow_headers: [''Origin'',''Accept'',''Content-Type'']
          allow_methods: [''POST'',''GET'',''DELETE'',''PUT'',''OPTIONS'']
          max_age: 3600
          hosts:
              - "^(https?://)?(back|api)/.mydomain.dev/?"

El controlador utilizado está extendiendo el de FOSRestBundle , tiene algo de seguridad (por ejemplo, no puede POST / PUT / DELETE cuando no tiene el rol correcto), puede actualizar objetos y devuelve solo datos JSON (hay un detector para eso) .

Comportamiento ideal

Idealmente, quiero esto:

1. Ejecute la solicitud jQuery AJAX POST / PUT / DELETE
2. Tiene que enviar una solicitud OPTIONS con todos los encabezados CORS
3. NelmioCorsBundle debe devolver los encabezados CORS correctos aceptando la solicitud que debe realizarse, incluso antes de ejecutar cualquier controlador dentro de la aplicación (realizada por el oyente de solicitud del paquete)
4. Si se acepta, la solicitud HTTP adecuada se envía al controlador con todos los datos de solicitud como una cadena JSON serializada (en la carga útil de la solicitud), y Symfony la recupera e interpreta la cadena JSON correcta como un objeto de matriz
5. El controlador obtiene los datos, hace sus cosas y devuelve una respuesta de application/json .

Problema

Pero aquí, probé todas las combinaciones, y parece que no puedo hacer que funcione.

Los puntos n ° 3 y 4 están fallando, total o parcialmente.

Intentó soluciones

1. Cuando no serializo los data con JSON.stringify (vea la parte de Configuración anterior), se envía la solicitud OPTIONS, pero FOSRestBundle envía una BadRequestHttpException dice Invalid json message received , y es totalmente normal porque la "carga útil de solicitud" (como se ve) en las herramientas para desarrolladores de Chrome) es el contenido clásico application/x-www-form-urlencoded , incluso si especifiqué contentType: "application/json" en la solicitud jQuery AJAX, mientras que debería ser una cadena JSON serializada.

2. Sin embargo, si serializo la var de data , la "carga útil de solicitud" es válida, pero la solicitud de OPCIONES no se envía, lo que hace que toda la solicitud falle debido a la falta de aceptación de CORS.

3. Si reemplazo contentType: "application/json" con application/x-www-form-urlencoded o multipart/form-data , y no serializo los datos, entonces, la carga útil de la solicitud es válida, pero la solicitud OPTIONS no se envía . También debería ser normal, como se explica en los documentos de jQuery en el parámetro contentType :

   Nota: Para las solicitudes de dominio cruzado, establecer el tipo de contenido en cualquier otra cosa que no sea application / x-www-form-urlencoded, multipart / form-data, o text / plain activará el navegador para enviar una solicitud de OPCIONES previas al servidor.

   Pero entonces, ¿cómo enviar una solicitud CORS correcta?

Preguntas

• ¿De dónde viene este problema?
• ¿Es esto un problema con mi configuración? Con jQuery?
• Con AJAX en sí?
• ¿Cuáles pueden ser las diferentes soluciones para resolver este maldito problema?

Edits (después de los comentarios)

2015-06-29 17:39

Condiciones:

En AJAX, contentType se establece en application/json . La opción de data se establece en una cadena JSON serializada.

Encabezados REQUEST de Preflight

OPTIONS http://api.mydomain.dev/fr/object/1 HTTP/1.1
Access-Control-Request-Method: POST
Origin: http://back.mydomain.dev
Access-Control-Request-Headers: accept, content-type
Referer: http://back.mydomain.dev/...

Jefes de RESPUESTA antes del vuelo

HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST, GET, DELETE, PUT, OPTIONS
Access-Control-Allow-Headers: origin, accept, content-type
Access-Control-Max-Age: 3600
Access-Control-Allow-Origin: http://back.mydomain.dev

POST REQUEST encabezados (después de la verificación previa)

POST http://api.mydomain.dev/fr/object/1 HTTP/1.1
Origin: http://back.mydomain.dev
Content-Type: application/json
Referer: http://back.mydomain.dev/...
Cookie: mydomainPortal=v5gjedn8lsagt0uucrhshn7ck1
Accept: application/json, text/javascript, */*; q=0.01

Carga de solicitud (en bruto): {"json":{"id":1,"name":"object"}}

Debe señalarse que esto arroja un error de javascript:

XMLHttpRequest no puede cargar http://api.mydomain.dev/fr/object/1 . Ningún encabezado ''Access-Control-Allow-Origin'' está presente en el recurso solicitado. El origen '' http://back.mydomain.dev '' no está, por lo tanto, permitido.

POST RESPONSE encabezados (después de la verificación previa)

HTTP/1.1 200 OK
Date: Mon, 29 Jun 2015 15:35:07 GMT
Server: Apache/2.4.12 (Unix) OpenSSL/1.0.2c Phusion_Passenger/5.0.11
Keep-Alive: timeout=5, max=91
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

2015-06-29 17:39

También traté de usar vainilla javascript para hacer XMLHttpRequest, el problema sigue siendo el mismo:

var xhr = new XMLHttpRequest;
xhr.open(''POST'', ''http://api.mydomain.dev/fr/objects/1'', true);
xhr.setRequestHeader(''Content-type'', ''application/json'');
xhr.withCredentials = true; // Sends cookie
xhr.onreadystatechange = function(e) {
    // A simple callback
    console.info(JSON.parse(e.target.response));
};
// Now send the request with the serialized payload:
xhr.send(''{"id":1,"name":"Updated test object"}'');

Luego, el navegador envía una solicitud de OPCIONES:

OPTIONS http://api.mydomain.dev/fr/objects/1 HTTP/1.1
Connection: keep-alive
Access-Control-Request-Headers: content-type
Access-Control-Request-Method: POST
Origin: http://back.mydomain.dev

Que devuelve los encabezados de respuesta correctos:

Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST, GET, DELETE, PUT, OPTIONS
Access-Control-Allow-Headers: origin, accept, content-type
Access-Control-Max-Age: 3600
Access-Control-Allow-Origin: http://back.mydomain.dev

Pero luego, el navegador envía la solicitud POST sin ningún encabezado "Access-Control- *".

Answer 1

En realidad, mi configuración funcionó bien.
Absolutamente perfecto, si pudiera decirlo.

Era solo una especie de ... Estupidez.

Una exit; estaba escondido en un archivo PHP.

Lo siento por molestia. Supongo que es una especie de registro en una proporción de texto / calidad en SO.

Editar: todavía espero que este problema pueda ser un ejemplo adecuado de un proyecto Symfony totalmente compatible con CORS.