whitelistParentDomain et whitelistIframeDomains whitelistparentdomain-and-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 section-f645198bbaba4fba8961acb6e88d1470
Les deux éléments de configuration sont requis lorsque vous utilisez ce code.
Exemple de code section-09d0049fe88a473baa69d404c50bf8ae
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 section-fc2eeb93546b406fae3b102dbcd11de7
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.
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.
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.
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.
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
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.
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.
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 section-2b1ce31fab034e1ca0f6b1c3cc57a6e2
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 section-30c6a9f4dcdc4265a1149260b97cc057
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.
- getMarketingCloudID
- getAudienceManagerLocationHint
- getAudienceManagerBlob
- getSupplementalDataID
- getCustomerIDs
- getSupplementalDataID
- getMarketingCloudVisitorID