Show Menu
TOPICS×

whitelistParentDomain y whitelistIframeDomains

Estas configuraciones permiten a diferentes instancias del código de servicio de ID implementadas en un iFrame y en la página principal comunicarse las unas con las otras. 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. Estas están disponibles en la versión 2.2 del código de VisitorAPI.js y en las posteriores.
Contenido:

Sintaxis

Se utilizan los dos elementos de configuración cuando 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 establecer una cookie de servicio de ID y asignar un ID de visitante cuando los navegadores bloquean cookies de terceros, y si se aplican una de estas condiciones:
  • Controla o no controla la página/dominio principal.
  • El código de servicio de ID no está instalado en la página principal, sino que está implementado en un iFrame.
You may also want to implement these configurations when you're serving video in an iFrame with Video Heartbeat . Video Heartbeat necesita un servicio de ID (el MID) para funcionar correctamente.
Caso de uso 1: El navegador bloquea cookies de terceros y el servicio de ID se implementa en el iFrame y la página principal
Elemento de caso de uso
Descripción
Condiciones
Este caso de uso incluye las condiciones siguientes:
  • La empresa A implementa el servicio de ID en su página de inicio.
  • La empresa A implementa el servicio de ID en iFrame en su página de inicio.
  • La empresa A es propietaria de la página principal y el iFrame ha implementado el servicio de ID en ambos lados.
  • Un cliente carga la página principal en un navegador que bloquea 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 navegador ve el iFrame como un dominio de terceros e impide que el servicio de ID establezca 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 al código de servicio de ID del iFrame comprobar el código de servicio de ID en la página principal para un ID de visitante.
Si el código de servicio de ID en el iFrame no recibe una página principal de respuesta, estas configuraciones generan un ID de visitante local.
Caso de uso 2: Solicitar un ID de un iFrame integrado en una página principal que usted no controla o que no utiliza el servicio de ID
Elemento de caso de uso
Descripción
Condiciones
Este caso de uso incluye las condiciones siguientes:
  • La empresa A no utiliza el servicio de ID.
  • La empresa A carga un iFrame en la página. Este iFrame pertenece a la empresa B y se carga en un dominio aparte que no pertenece a la empresa A.
  • El navegador bloquea las cookies de terceros.
Resultados
Dadas estas condiciones, el servicio de ID:
  • No funciona en el iFrame. Esto se debe a que el navegador ve el iFrame como un dominio de terceros e impide que el servicio de ID establezca la cookie AMCV.
  • No puede obtener un ID de visitante de la página principal porque la empresa 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 al código de servicio de ID del iFrame comprobar el código de servicio de ID en la página principal para un ID de visitante.
Si el código de servicio de ID en el 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 de iFrame deben utilizar el mismo ID de organización. Estas configuraciones de lista de elementos permitidos no funcionarán cuando los ID de organización de la página principal o del iFrame son 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 previsto, no se podrá realizar este proceso de uso compartido.

Métodos de API de visitante compatibles

El servicio de ID admite un conjunto limitado de métodos API públicos cuando implementa estas configuraciones de listas de elementos permitidos. Los métodos admitidos varían en función de los escenarios de casos de uso descritos anteriormente.
Caso de uso
Métodos compatibles
Caso 1
  • getMarketingCloudID
  • getAudienceManagerLocationHint
  • getAudienceManagerBlob
  • getSupplementalDataID
  • getCustomerIDs
Caso 2
  • getSupplementalDataID
  • getMarketingCloudVisitorID