whitelistParentDomain et whitelistIframeDomains

Ces configurations permettent à différentes instances du code du service d’ID implémentées dans un iFrame et sur la page parente de communiquer entre elles. Elles sont conçues pour aider à résoudre les problèmes liés à deux cas d’utilisation spécifiques où vous pouvez contrôler ou non la page/le domaine parent et où le code du service d’ID est chargé dans l’iFrame d’un domaine que vous contrôlez. Elles sont disponibles dans le code VisitorAPI.js version 2.2 ou ultérieure.

Contenu :

Syntaxe

Les deux éléments de configuration sont requis lorsque vous utilisez ce code.

Syntaxe de la configuration Description

whitelistParentDomain: " Nom de domaine de la page parente"

Accepte un seul nom de domaine transmis en tant que chaîne.

whitelistIframeDomains: [ "domaine iFrame","domaine iFrame","domaine iFrame" ]

Accepte un ou plusieurs noms de domaine iFrame transmis en tant que tableau.

Exemple de code

Le code du service d’ID que vous avez configuré pourrait ressembler à cet exemple.

//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"], 
 ... 
 } 
);

Cas d’utilisation

Ces configurations permettent de résoudre le problème de définition d’un cookie du service d’ID et d’attribution d’un ID de visiteur lorsque les navigateurs bloquent les cookies tiers et si l’une des conditions suivantes s’applique :

  • Vous contrôlez ou ne contrôlez pas la page/domaine parent.
  • Le code du service d’ID n’est pas installé sur la page parente, mais est implémenté dans un iFrame.
CONSEIL

Vous pouvez également mettre en œuvre ces configurations lorsque vous diffusez de la vidéo dans un iFrame avec Video Heartbeat. Video Heartbeat a besoin d’un service d’ID (le MID) pour fonctionner correctement.

Exemple d’utilisation 1 : Le navigateur bloque les cookies tiers et le service d’ID est implémenté sur l’iFrame et la page parente.

Elément d’exemple d’utilisation Description

Conditions

Cet exemple d’utilisation comprend les conditions suivantes :

  • La Société A met en œuvre le service d’ID sur leur page d’accueil.
  • La Société A met en œuvre le service d’ID dans iFrame sur leur page d’accueil.
  • La Société A possède la page parente et l’iFrame et a mis en œuvre le service d’ID aux deux emplacements.
  • Un client charge la page parente dans un navigateur qui bloque les cookies tiers.

Résultats

Dans ces conditions, le service d’ID :

  • Fonctionne correctement sur la page parente. Il demande et définit le cookie AMCV et affecte un ID unique au visiteur du site.
  • Ne fonctionne pas dans l’iFrame. En effet, le navigateur considère l’iFrame comme un domaine tiers et empêche le service d’ID de définir le cookie AMCV.

Solution

Modifiez la fonction Visitor.getInstance du service d’ID dans l’iFrame avec les configurations de liste blanche. Spécifiez les domaines parent et enfant dans le code. Ces configurations permettent au code du service d’ID de l’iFrame de vérifier le code du service d’ID sur la page parente pour un ID de visiteur.

Si le code du service d’ID de l’iFrame ne reçoit pas de page parente de réponse, ces configurations génèrent un identifiant de visiteur local.

Exemple d’utilisation 2 : Demande d’un identifiant à partir d’un iFrame incorporé dans une page parente que vous ne contrôlez pas ou qui n’utilise pas le service d’ID

Elément d’exemple d’utilisation Description

Conditions

Cet exemple d’utilisation comprend les conditions suivantes :

  • La Société A n’utilise pas le service d’ID.
  • La Société A charge un iFrame sur la page. Cet iFrame appartient à la Société B et est chargé dans un domaine distinct de la Société A.
  • Le navigateur bloque les cookies tiers.

Résultats

Dans ces conditions, le service d’ID :

  • Ne fonctionne pas dans l’iFrame. En effet, le navigateur considère l’iFrame comme un domaine tiers et empêche le service d’ID de définir le cookie AMCV.
  • Impossible d’obtenir un ID de visiteur à partir de la page parente, car la Société A n’utilise pas ce service.

Solution

Modifiez la fonction Visitor.getInstance du service d’ID dans l’iFrame avec les configurations de liste blanche. Spécifiez les domaines parent et enfant dans le code. Ces configurations permettent au code du service d’ID de l’iFrame de vérifier le code du service d’ID sur la page parente pour un ID de visiteur.

Si le code du service d’ID de l’iFrame ne reçoit pas de page parente de réponse, ces configurations génèrent un identifiant de visiteur local.

Sécurité des configurations

Vous pouvez mettre en œuvre ces configurations en toute sécurité car :

  • Le service d’ID implémenté sur le domaine parent et le domaine iFrame doivent utiliser le même ID d’organisation. Ces configurations de liste blanche ne fonctionneront pas lorsque les ID d’organisation sur le parent ou dans l’iFrame sont différents.
  • Ces configurations communiquent uniquement avec le domaine et les iFrames spécifiés dans le code.
  • La communication entre l’iFrame et la page parente suit un format spécifique. Si le service d’ID de la page parente ne reçoit pas de demande au format attendu, ce processus de partage échoue.

Méthodes API visiteur prises en charge

Le service d’ID prend en charge un ensemble limité de méthodes API publiques lorsque vous implémentez ces configurations de liste blanche. Les méthodes prises en charge varient en fonction des scénarios d’utilisation décrits ci-dessus.

Exemple d’utilisation Méthodes prises en charge

Cas 1

  • getMarketingCloudID
  • getAudienceManagerLocationHint
  • getAudienceManagerBlob
  • getSupplementalDataID
  • getCustomerIDs

Cas 2

  • getSupplementalDataID
  • getMarketingCloudVisitorID

Sur cette page