Quiero crear una aplicación de página única (SPA) y noté el siguiente problema durante la separación de la API de backend (REST) y los activos de frontend (código estático vue.js) :
Cuando se entrega index.html desde otro dominio que no sea el backend de la API, la mayoría de las solicitudes POST/PUT desencadenan una solicitud de verificación previa de CORS.
Investigué un poco y descubrí que las publicaciones de blog [1][2] discuten este problema, sin dar una solución práctica. Algunos encabezados (por ejemplo, el encabezado de autorización y el encabezado de tipo de contenido con el valor application/json ) no están permitidos como encabezado de solicitud cors-safelisted. Por lo tanto, las solicitudes POST/PUT desencadenan una solicitud de verificación previa de CORS. Esto no es aceptable ya que agrega una cantidad considerable de latencia.
¿Es posible evitar estas solicitudes de verificación previa si ambos dominios pertenecen a la misma entidad?
Investigué un poco sobre cómo evitar las solicitudes de CORS entre el frontend y el backend. La solución requiere que el archivo index.html se sirva desde el mismo dominio que el backend de la API REST (consulte el Ejemplo a continuación). Me pregunto si no usar dominios separados es la única solución para evitar las solicitudes de CORS para SPA.
[1] https://www.freecodecamp.org/news/the-terrible-performance-cost-of-cors-api-on-the-single-page-application-spa-6fcf71e50147/
[2] https://developer.akamai.com/blog/2015/08/17/solution-options-performance-issue-spas
¿Cómo evitar las solicitudes de verificación previa de CORS en aplicaciones de una sola página?
Primero, no se puede "evitar" algo que es parte del estándar. En segundo lugar, esta pregunta está mal formulada, ya que los propios SPA pueden usar o no CORS. Esto depende completamente de su configuración/diseño. Si desea evitar la verificación previa, simplemente no solicite recursos de otros orígenes.
¿Es posible evitar estas solicitudes de verificación previa si ambos dominios pertenecen a la misma entidad?
No.
La propiedad del sitio no tiene nada que ver con CORS. Uso compartido de recursos entre orígenes significa que desea compartir recursos entre diferentesorígenes . No necesariamente entre diferentes dominios. El origen no es entidad ni propietario. El origen es solo una parte de una URL.
La mejor solución es evitar la introducción del problema CORS por completo y apegarse siempre al mismo origen. Su suposición de que debe separar la API de back-end de los activos de front-end con diferentes orígenes no es cierta.
La introducción de múltiples orígenes y dominios en su configuración está agregando más problemas de los que resuelve. Idealmente, toda su configuración debe ocultarse de los clientes que se conectan y reducirse a un único dominio y origen.
La configuración que desea
-> static file server CDN -> Load balancer -> api server -> api server -> ...Ejemplo de configuración
Use su balanceador de carga y sus reglas de ACL. Dígale que dirija todo el tráfico hacia donde debe ir. Usaré haproxy como ejemplo, porque eso es lo que uso y porque, por lo que sé, es bastante estándar de la industria en términos de solución de equilibrio de carga de software.
Esta no es la configuración completa, solo una parte relevante relacionada con el tráfico de enrutamiento.
# part of haproxy configuration file, usually located at /etc/haproxy/haproxy.cfg frontend http-in # this is where requests get in to load balancer bind *:80 acl data path_beg /api # "catch" any request with path beginning with "/api" use_backend api if data # then route it to api backend defined below default_backend static # any non-matching request we direct to static file server backend static server node1 127.0.0.1:3000 # server hosting static files (index.html) backend api server node1 127.0.0.1:4000 # application servers server node2 ...No hay muchas opciones allí.
La solución más simple sería entregar el html y los activos desde el mismo dominio que su API.
La segunda opción es usar solo encabezados que sean cors-safelisted-request-header.
Lo que noté:
El encabezado Content-Type se puede reemplazar con el encabezado de Accept . Este encabezado está bien.
Si está realizando solicitudes XHR, puede omitir el encabezado de Authentication y, en su lugar, agregar la información de autenticación automáticamente configurando el campo withCredentials de su solicitud XHR en verdadero. Ejemplo de VanillaJS:
var xhr = new XMLHttpRequest(); xhr.open('GET', 'https://www.example.org/api/whatever', true); xhr.withCredentials = true; xhr.send();Si está utilizando cualquier otro cliente XHR, consulte los documentos si se puede configurar la opción.
Otra opción sería autenticarse con cookies y sesiones del lado del servidor. Como está utilizando AWS, AWS Cognito podría ser una opción.
Si hay más encabezados en uso que no son un encabezado CORS en la lista segura, debe deshacerse de ellos.
Access-Control-Max-Age puede ayudar:
El encabezado de respuesta
Access-Control-Max-Ageindica cuánto tiempo se pueden almacenar en caché los resultados de una solicitud de verificación previa (es decir, la información contenida en los encabezadosAccess-Control-Allow-MethodsyAccess-Control-Allow-Headers).
... En realidad, el enlace que has publicado lo menciona:
Podrías decir que sí. Podemos usar el encabezado Access-Control-Max-Age para almacenar en caché los resultados de una solicitud de verificación previa.
Luego continúan con la advertencia:
La forma en que funciona la caché de verificación previa es por URL, no solo por el origen. Esto significa que cualquier cambio en la ruta (que incluye los parámetros de consulta) justifica otra solicitud de verificación previa.
Pero puede seguir usando la misma URL y enviar todos los parámetros en el cuerpo de la solicitud.
También
¿Es posible evitar estas solicitudes de verificación previa si ambos dominios pertenecen a la misma entidad?
No. No existe una forma práctica para que un navegador verifique la propiedad de los dominios. A veces, incluso para un humano, no es una tarea fácil.