whitelistParentDomain und whitelistIframeDomains whitelistparentdomain-and-whitelistiframedomains
Mit diesen Konfigurationen können verschiedene Instanzen des ID-Dienst-Codes, die in einem iFrame und auf der übergeordneten Seite implementiert sind, miteinander kommunizieren. Sie sollen dabei helfen, Probleme in zwei konkreten Nutzungsszenarios zu lösen, in denen Sie die übergeordnete Seite/Domain verwalten oder auch nicht und bei denen ID-Dienstcode im iFrame einer von Ihnen verwalteten Domain geladen wird. Sie sind in Version 2.2 (oder höher) des VisitorAPI.js-Codes verfügbar.
Inhalt:
Syntax section-f645198bbaba4fba8961acb6e88d1470
Beide Konfigurationselemente sind erforderlich, wenn Sie diesen Code verwenden.
Codebeispiel section-09d0049fe88a473baa69d404c50bf8ae
Der konfigurierte ID-Dienstcode sollte in etwa wie im folgenden Beispiel aussehen.
//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"],
...
}
);
Anwendungsfälle section-fc2eeb93546b406fae3b102dbcd11de7
Diese Konfigurationen helfen, das Problem zu lösen, ein ID-Dienst-Cookie zu setzen und eine Besucher-ID zuzuweisen, wenn Browser Drittanbieter-Cookies blockieren und eine der folgenden Bedingungen zutrifft:
- Sie steuern die übergeordnete Seite/Domain oder steuern sie nicht.
- Der ID-Dienst-Code wird nicht auf der übergeordneten Seite installiert, sondern in einem iFrame implementiert.
Nutzungsszenario 1: Der Browser blockiert Drittanbieter-Cookies und der ID-Dienst wird auf der iFrame- und der übergeordneten Seite implementiert
Dieses Nutzungsszenario schließt die folgenden Bedingungen ein:
- Firma A implementiert den ID-Dienst auf ihrer Startseite.
- Firma A implementiert den ID-Dienst in iFrame auf ihrer Startseite.
- Firma A besitzt ist der Eigentümer der übergeordneten Seite und des iFrame und hat den ID-Dienst für beide implementiert.
- Ein Kunde lädt die übergeordnete Seite in einen Browser, der Drittanbieter-Cookies blockiert.
Unter diesen Bedingungen gilt für den ID-Dienst:
- Er funktioniert ordnungsgemäß auf der übergeordneten Seite. Er fordert das AMCV-Cookie an, setzt es und weist dem Site-Besucher eine eindeutige ID zu.
- Funktioniert nicht im iFrame. Dies liegt daran, dass der Browser den iFrame als Drittanbieterdomäne ansieht und den ID-Dienst daran hindert, das AMCV-Cookie zu setzen.
Ändern Sie die Funktion Visitor.getInstance des ID-Diensts im iFrame mit diesen Whitelist-Konfigurationen. Geben Sie die übergeordneten und untergeordneten Domänen im Code an. Mit diesen Konfigurationen kann der ID-Dienst-Code im iFrame den ID-Dienst-Code auf der übergeordneten Seite auf eine Besucher-ID überprüfen.
Wenn der ID-Dienst-Code im iFrame keine Antwort von der übergeordneten Seite erhält, generieren diese Konfigurationen eine lokale Besucher-ID.
Nutzungsszenario 2: Anfordern einer ID aus einem iFrame, der in eine übergeordnete Seite eingebettet ist, die Sie nicht steuern und die den ID-Dienst nicht verwendet
Dieses Nutzungsszenario schließt die folgenden Bedingungen ein:
- Firma A verwendet den ID-Dienst nicht.
- Firma A lädt einen iFrame auf die Seite. Dieser iFrame gehört Firma B und wird in einer anderen Domain als Firma A geladen.
- Der Browser blockiert Drittanbieter-Cookies.
Unter diesen Bedingungen gilt für den ID-Dienst:
- Funktioniert nicht im iFrame. Dies liegt daran, dass der Browser den iFrame als Drittanbieterdomäne ansieht und den ID-Dienst daran hindert, das AMCV-Cookie zu setzen.
- Es kann keine Besucher-ID von der übergeordneten Seite abgerufen werden, da Firma A diesen Service nicht verwendet.
Ändern Sie die Funktion Visitor.getInstance des ID-Diensts im iFrame mit diesen Whitelist-Konfigurationen. Geben Sie die übergeordneten und untergeordneten Domänen im Code an. Mit diesen Konfigurationen kann der ID-Dienst-Code im iFrame den ID-Dienst-Code auf der übergeordneten Seite auf eine Besucher-ID überprüfen.
Wenn der ID-Dienst-Code im iFrame keine Antwort von der übergeordneten Seite erhält, generieren diese Konfigurationen eine lokale Besucher-ID.
Sicherheit der Konfiguration section-2b1ce31fab034e1ca0f6b1c3cc57a6e2
Sie können diese Konfigurationen aus folgenden Gründen sicher implementieren:
- Der in der übergeordneten Domain implementierte ID-Dienst und die iFrame-Domäne müssen dieselbe Organisations-ID verwenden. Diese Whitelist-Konfigurationen funktionieren nicht, wenn die Organisations-IDs auf der übergeordneten Seite oder im iFrame unterschiedlich sind.
- Diese Konfigurationen kommunizieren nur mit der Domain und den iFrames, die im Code angegeben sind.
- Die Kommunikation zwischen dem iFrame und der übergeordneten Seite folgt einem bestimmten Format. Wenn der ID-Dienst auf der übergeordneten Seite keine Anforderung im erwarteten Format erhält, schlägt dieser Freigabeprozess fehl.
Unterstützte Besucher-API-Methoden section-30c6a9f4dcdc4265a1149260b97cc057
Der ID-Dienst unterstützt einen begrenzte Anzahl an öffentlichen API-Methoden, wenn Sie diese Whitelist-Konfigurationen implementieren. Die unterstützten Methoden variieren je nach den oben beschriebenen Nutzungsszenarios.
- getMarketingCloudID
- getAudienceManagerLocationHint
- getAudienceManagerBlob
- getSupplementalDataID
- getCustomerIDs
- getSupplementalDataID
- getMarketingCloudVisitorID