Compatibilidad con CORS en el servicio de identidad de Experience Cloud cors-support-in-the-experience-cloud-id-service

Los navegadores utilizan Cross Origin Resource Sharing (CORS) para solicitar recursos de un dominio que no es el dominio en uso. El servicio de identidad de Experience Cloud admite los estándares CORS que habilitan solicitudes de recursos de origen diverso del lado del cliente. El servicio de ID cambia a solicitudes JSONP en los navegadores más antiguos o que no admiten el mecanismo CORS.

Problemas con políticas del mismo origen y solicitudes del servicio de ID section-6608cf46d27143eeaeabacaa6aa14e8e

Las políticas del mismo origen son controles de seguridad o restricciones que aplica un explorador web. Cuando se aplica en este nivel, el propio explorador web determina si se permitirá o bloqueará una solicitud de recursos realizada de una página a otra. Para determinar si una solicitud es del mismo origen, el explorador compara:

  • Identificadores de recursos uniformes (URI)
  • Nombres de host (por ejemplo, http://www.my-webpage-example.com)
  • Números de puerto (por ejemplo, puerto 80 y 440 para solicitudes HTTP y HTTPS)

El explorador permite que una solicitud se realice correctamente si ambas páginas comparten estas características y bloquea las solicitudes de recursos si no lo hacen.

CORS resuelve problemas con políticas del mismo origen section-76c87ec3295d447bab220c84f138c235

CORS es una forma segura y eficaz de solicitar recursos en distintos dominios. La especificación CORS incluye un conjunto de encabezados HTTP que los exploradores utilizan para enviar, recibir y evaluar solicitudes de recursos. La evaluación de una solicitud de recurso se denomina preflight check. Esta comprobación permite a los exploradores y servidores determinar qué solicitudes están permitidas o bloqueadas. La comprobación preliminar es transparente para la aplicación, la API o el script que solicita un recurso. Dos encabezados importantes en el proceso de solicitud de recursos son:

  • Origin: un encabezado de solicitud que identifica el origen de una solicitud.
  • Access-Control-Allow-Origin: un encabezado de respuesta que indica si se puede compartir un recurso con el solicitante.

Veamos el funcionamiento de estos encabezados. En este ejemplo, supongamos que tenemos una empresa de servicios financieros que ha implementado el servicio de Experience Cloud ID de en su sitio, www.finance-website.com. La siguiente tabla define cómo los encabezados de solicitud y respuesta CORS comprueban el acceso a un recurso.

Acción
Descripción
Solicitud

Cuando se carga la página de la empresa de finanzas, el navegador realiza una solicitud a dpm.demdex.net. Se trata de una llamada al dominio de los servidores de recopilación de datos (DCS) que utiliza el servicio de ID. Esta solicitud entre dominios incluye el encabezado:

  • Origin//www.finance-website.com
Respuesta

La respuesta del dominio DCS incluye estos encabezados que proporcionan al sitio de la empresa financiera acceso a los recursos necesarios:

  • Access-Control-Allow-Origin: https://www.finance-website.com
  • Access-Control-Allow-Credentials: true

Consulte también useCORSOnly.

Otras ventajas del uso de CORS section-6f44f30694c44f95bf9854b8a2af8449

La tabla siguiente describe algunas de las ventajas que CORS ofrece a los clientes que utilizan el servicio de ID.

Ventaja
Descripción
Mayor seguridad

CORS utiliza XMLHttpRequest para solicitar y transferir datos. Este método es más seguro que una solicitud JSONP. Garantiza que no hay forma de ejecutar JavaScript arbitrario, que podría estar contenido en la respuesta del DCS. La carga útil de respuesta CORS XMLHttpRequest la analiza el JavaScript del servicio de ID y no se ejecuta simplemente en una función de llamada de retorno.

Nota: Para aceptar cookies, el objeto XMLHttpRequest tiene que tener su propiedad withCredentials establecida en true. Esta propiedad es compatible con Chrome, Firefox, Internet Explorer (v10+), Opera y Safari.

Mejoras en el rendimiento

CORS ayuda a mejorar el rendimiento por estos motivos:

  • El explorador gestiona las solicitudes de recursos. El proceso de solicitud es transparente para el servicio de ID.
  • A diferencia de las solicitudes JSONP asincrónicas, el explorador no anula la prioridad de las solicitudes CORS ni las pone en cola.
  • El servicio de ID responde permisivamente. Esto significa que, cuando se ha pasado una URL como Origin, el servicio de ID concederá a la página acceso a los recursos solicitados.
recommendation-more-help
9c9e8ca9-9f7e-42c9-a5d5-a0d82776362a