Problemas comunes de integración desde el front end parte 1 (CORS + Solicitud de verificación previa — Traduccion al español)
Cuando hablamos de aplicaciones del lado del cliente, ventajas de los microservicios y micro-frontend, integraciones del lado del cliente y hacer que nuestras aplicaciones sean más independientes, estamos normalmente hablando de estos problemas.
CORS (uso compartido de recursos de origen cruzado) por motivos de comunicación de seguridad, los navegadores restringen las solicitudes entre dominios, pero ¿qué es una solicitud entre dominios? imagina una web servida desde una URL
https://my.web.comQue pide recursos a través de XMLHttpRequest de otra como esta se puede hacer a través de los métodos GET, POST, PUT o PATCH.
https://other.web.net/some-resource.jsonEsta es una solicitud entre dominios porque son dominios separados que podrían ser propiedad de diferentes desarrolladores / organizaciones y, por eso, el navegador debe asegurarse de que podamos acceder a estos recursos de forma segura.
Aquí es donde CORS ayudó a que todos los recursos que se deben obtener a través de la API Fetch o XMLHttpRequest deben venir con encabezados adicionales.
El encabezado principal que nos permite consumir recursos es Access-Control-Allow-Origin, este encabezado se puede configurar para permitir cualquier origen consumir nuestros recursos así:
Access-Control-Allow-Origin: *ó solo restringirlo a algún sitio así:
Access-Control-Allow-Origin: https://my.web.comCon eso, restringimos el acceso a nuestros recursos consumidos directamente desde el navegador, pero hacer que suceda en todas las solicitudes a veces es costoso, imagina que tienes que subir a través de una publicación una imagen grande y después de enviar toda esta solicitud grande, te das cuenta de que tu URL no está permitido consumir este servicio, y es ahí donde vinieron Preflight Requests para ayudar, estos request están íntimamente relacionados con CORS porque cuando necesitamos acceder a un recurso externo como este desde nuestro sitio web, el navegador envía una solicitud con el método OPTIONS al servidor antes de enviar el principal para verificar si se puede hacer esta solicitud, normalmente verifica si el método de solicitud es aceptado y si el encabezado de origen está presente en este recurso, con esta información y antes de enviar cualquier payload al navegador puede verificar el estado el estado y la capacidad del servicio para ejecutar la solicitud.
Este tipo de solicitud se llama Solicitud Preflight y se llama automáticamente directamente desde el navegador, no por el código de la interfaz sino al cumplir una serie de caracteristicas, pero el navegador mismo realiza la solicitud para optimizar los recursos del cliente (evitando la costosa llamada de una API si no tiene seguridad acceso o está inactivo).
Para finalizar, aquí hay un gráfico que representa la forma en que se dice cuándo se llama a la solicitud de prefight desde
y un pre-request script para postman para probar si el prefight request debe ser llamado y si responde ok:
