Show Menu
TOPICS×

whitelistParentDomain y whitelistIframeDomains

Estas configuraciones permiten que diferentes instancias del código de servicio de ID implementadas en un iFrame y en la página principal se comuniquen entre sí. Están diseñadas para ayudar a resolver problemas con 2 casos de uso específicos en los que puede que sea posible, o no, controlar la página o el dominio principal y en los que tenga el código de servicio de ID cargando en el iFrame de un dominio que controla. Están disponibles en la versión 2.2 o posterior del código de VisitorAPI.js.
Contenido:

Sintaxis

Ambos elementos de configuración son obligatorios cuando se utiliza este código.
Sintaxis de configuración
Descripción
whitelistParentDomain: "
Nombre del dominio de la página principal
"
Acepta un nombre de dominio transferido como una cadena.
whitelistIframeDomains: [
"Dominio de iFrame","Dominio de iFrame","Dominio de iFrame"
]
Acepta uno o más nombres de dominio de iFrame transferidos como una matriz.

Ejemplo de código

Su código de servicio de ID configurado puede tener un aspecto similar al de este ejemplo.
//Instantiate Visitor var visitor = Visitor.getInstance("Insert Experience Cloud Organization ID here",{ ... //Add parent page domain name and iFrame domain names whitelistParentDomain: "parentpageA.com", whitelistIframeDomains: ["iFrameDomain1.com","iFrameDomain2.com"], ... } );

Casos de uso

Estas configuraciones ayudan a resolver el problema de configurar una cookie de servicio de ID y asignar un ID de visitante cuando los exploradores bloquean cookies de terceros y si se aplican cualquiera de estas condiciones:
  • Usted controla o no la página/dominio principal.
  • El código de servicio de ID no está instalado en la página principal, pero se implementa en un iFrame.
También es posible que desee implementar estas configuraciones cuando vaya a ofrecer vídeo en un iFrame con Video Heartbeat . Video Heartbeat necesita un ID de servicio de ID (el MID) para funcionar correctamente.
Caso de uso 1: El explorador bloquea las cookies de terceros y el servicio de ID se implementa en la página principal y en el iFrame
Elemento de caso de uso
Descripción
Condiciones
Este caso de uso incluye las siguientes condiciones:
  • La compañía A implementa el servicio de ID en su página de inicio.
  • La compañía A implementa el servicio de ID en iFrame en su página de inicio.
  • La compañía A posee la página principal y el iFrame y ha implementado el servicio de ID en ambos lugares.
  • Un cliente carga la página principal en un explorador que bloquea las cookies de terceros.
Resultados
Dadas estas condiciones, el servicio de ID:
  • Funciona correctamente en la página principal. Solicita y establece la cookie AMCV y asigna un ID único al visitante del sitio.
  • No funciona en el iFrame. Esto se debe a que el explorador ve el iFrame como un dominio de terceros y evita que el servicio de ID configure la cookie AMCV.
Solución
Modifique la función
Visitor.getInstance
del servicio de ID en el iFrame con estas configuraciones de listas de elementos permitidos. Especifique los dominios principal y secundario en el código. Estas configuraciones permiten que el código de servicio de ID en el iFrame compruebe el código de servicio de ID en la página principal para obtener un ID de visitante.
Si el código de servicio de ID del iFrame no recibe una página principal de respuesta, estas configuraciones generan un ID de visitante local.
Caso de uso 2: Solicitud de un ID desde un iFrame incrustado en una página principal que no controla o que no utiliza el servicio de ID
Elemento de caso de uso
Descripción
Condiciones
Este caso de uso incluye las siguientes condiciones:
  • La compañía A no utiliza el servicio de ID.
  • La compañía A carga un iFrame en la página. Este iFrame es propiedad de la compañía B y se carga en un dominio independiente al de la compañía A.
  • El explorador bloquea las cookies de terceros.
Resultados
Dadas estas condiciones, el servicio de ID:
  • No funciona en el iFrame. Esto se debe a que el explorador ve el iFrame como un dominio de terceros y evita que el servicio de ID configure la cookie AMCV.
  • No se puede obtener un ID de visitante de la página principal porque la compañía A no utiliza este servicio.
Solución
Modifique la función
Visitor.getInstance
del servicio de ID en el iFrame con estas configuraciones de listas de elementos permitidos. Especifique los dominios principal y secundario en el código. Estas configuraciones permiten que el código de servicio de ID en el iFrame compruebe el código de servicio de ID en la página principal para obtener un ID de visitante.
Si el código de servicio de ID del iFrame no recibe una página principal de respuesta, estas configuraciones generan un ID de visitante local.

Protección y seguridad de configuración

Puede implementar estas configuraciones de forma segura porque:
  • El servicio de ID implementado en el dominio principal y el dominio iFrame deben utilizar el mismo ID de organización. Estas configuraciones de lista blanca no funcionarán cuando los ID de organización del elemento principal o del iFrame sean diferentes.
  • Estas configuraciones solo se comunican con el dominio y los iFrames especificados en el código.
  • La comunicación entre el iFrame y la página principal sigue un formato específico. Si el servicio de ID de la página principal no recibe una solicitud en el formato esperado, este proceso de uso compartido fallará.

Métodos de API de visitante compatibles

El servicio de ID admite un conjunto limitado de métodos API públicos al implementar estas configuraciones de lista blanca. Los métodos admitidos varían según los casos de uso descritos anteriormente.
Caso de uso
Métodos admitidos
Caso 1
  • getMarketingCloudID
  • getAudienceManagerLocationHint
  • getAudienceManagerBlob
  • getSupplementalDataID
  • getCustomerIDs
Caso 2
  • getSupplementalDataID
  • getMarketingCloudVisitorID