Show Menu
TOPICS×

whitelistParentDomain et whitelistIframeDomains

Ces configurations permettent à différentes instances du code du service d’ID mises en œuvre dans un iFrame et sur la page parente de communiquer les unes avec les autres. Elles visent à résoudre des problèmes survenant dans 2 cas d’utilisation : vous pouvez (ou non) contrôler la page ou le domaine parent et le code du service d’ID se charge dans l’iFrame d’un domaine que vous ne contrôlez pas. Elles sont disponibles dans VisitorAPI.js 2.2 ou version ultérieure.
Contenu :

Syntaxe

Les deux éléments de configuration sont requis lors de l’utilisation de 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 identifiant 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/le domaine parent.
  • Le code du service d’ID n’est pas installé sur la page parente, mais est mis en œuvre dans un iFrame.
You may also want to implement these configurations when you're serving video in an iFrame with Video Heartbeat . La mesure de pulsation vidéo requiert un ID du service d’ID (le MID) pour fonctionner correctement.
Cas d’utilisation 1 : le navigateur bloque les cookies tiers et le service d’ID est mis en œuvre sur l’iFrame et la page parente
Élément du cas d’utilisation
Description
Conditions
Ce cas d’utilisation comprend les conditions suivantes :
  • La société A met en œuvre le service d’ID sur sa page d’accueil.
  • La société A met en œuvre le service d’ID dans un iFrame sur sa 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 attribue un identifiant 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. Indiquez les domaines parent et enfant dans le code. Ces configurations permettent au code du service d’ID dans l’iFrame de vérifier le code du service d’ID sur la page parente pour un identifiant visiteur.
Si le code du service d’ID dans l’iFrame ne reçoit pas une page parente de réponse, ces configurations génèrent un identifiant visiteur local.
Cas d’utilisation 2 : demander un ID à partir d’un iFrame incorporé dans une page parente que vous ne contrôlez pas ou qui n’utilise pas le service d’ID
Élément du cas d’utilisation
Description
Conditions
Ce cas 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 celui 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.
  • Ne peut pas obtenir un identifiant visiteur 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. Indiquez les domaines parent et enfant dans le code. Ces configurations permettent au code du service d’ID dans l’iFrame de vérifier le code du service d’ID sur la page parente pour un identifiant visiteur.
Si le code du service d’ID dans l’iFrame ne reçoit pas une page parente de réponse, ces configurations génèrent un identifiant visiteur local.

Sécurité des configurations

Vous pouvez mettre en œuvre ces configurations en toute sécurité car :
  • Le service d’ID mis en œuvre sur le domaine parent et celui mis en œuvre sur le domaine iFrame doivent utiliser le même ID d’organisation. Ces configurations de liste blanche ne fonctionneront pas lorsque les ID d’organisation du parent ou dans l’iFrame sont différents.
  • Ces configurations communiquent uniquement avec le domaine et les iFrames indiqués dans le code.
  • La communication entre l’iFrame et la page parente adopte un format spécifique. Si le service d’ID sur la page parente ne reçoit pas une requête au format attendu, le 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 mettez en œuvre ces configurations de liste blanche. Les méthodes prises en charge varient en fonction des scénarios de cas 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