whitelistParentDomain und whitelistIframeDomains whitelistparentdomain-and-whitelistiframedomains
Mit diesen Konfigurationen können verschiedene Instanzen des Besucher-ID-Dienst-Codes, die in einem iFrame implementiert sind und sich auf der übergeordneten Seite befinden, miteinander kommunizieren. Sie sollen dabei helfen, Probleme in zwei bestimmten Anwendungsfällen zu lösen, in denen Sie die übergeordnete Seite/Domain steuern oder auch nicht und bei denen der Besucher-ID-Dienst-Code im iFrame einer Domain geladen wird, die Sie steuern. Sie sind in VisitorAPI.js Code-Version 2.2 oder höher verfügbar.
Inhalt:
Syntax section-f645198bbaba4fba8961acb6e88d1470
Beide Konfigurationselemente sind erforderlich, wenn Sie diesen Code verwenden.
Codebeispiel section-09d0049fe88a473baa69d404c50bf8ae
Der konfigurierte Visitor ID Service-Code sollte in etwa wie im folgenden Beispiel aussehen.
//Instantiate Visitor
var visitor = Visitor.getInstance("INSERT-IMS-ORG-ID-HERE",{
...
//Add parent page domain name and iFrame domain names
whitelistParentDomain: "parentpageA.com",
whitelistIframeDomains: ["iFrameDomain1.com","iFrameDomain2.com"],
...
}
);
Anwendungsfälle section-fc2eeb93546b406fae3b102dbcd11de7
Mit diesen Konfigurationen können Sie das Problem lösen, ein Besucher-ID-Service-Cookie festzulegen 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 Besucher-ID-Dienst-Code ist nicht auf der übergeordneten Seite installiert, sondern in einem iFrame implementiert.
Anwendungsfall 1: Der Browser blockiert Cookies von Drittanbietern, und der Besucher-ID-Service ist auf dem iFrame und der übergeordneten Seite implementiert
Dieses Nutzungsszenario schließt die folgenden Bedingungen ein:
- Unternehmen A implementiert den Besucher-ID-Service auf seiner Startseite.
- Unternehmen A implementiert den Besucher-ID-Service in iFrame auf der Startseite.
- Unternehmen A ist für die übergeordnete Seite und den iFrame verantwortlich und hat den Besucher-ID-Service an beiden Stellen implementiert.
- Ein Kunde lädt die übergeordnete Seite in einen Browser, der Drittanbieter-Cookies blockiert.
Unter diesen Bedingungen hat der Besucher-ID-Dienst folgende Möglichkeiten:
- 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 Domain eines Drittanbieters betrachtet und den Besucher-ID-Service daran hindert, das AMCV-Cookie zu setzen.
Mit diesen Konfigurationen für die weiße Liste können Sie den Besucher-ID-Dienst die Funktion Visitor.getInstance im iFrame ändern. Geben Sie die übergeordneten und untergeordneten Domänen im Code an. Mit diesen Konfigurationen kann der Besucher-ID-Dienst-Code im iFrame den Besucher-ID-Dienst-Code auf der übergeordneten Seite auf eine Besucher-ID überprüfen.
Wenn der Besucher-ID-Dienst-Code im iFrame keine übergeordnete Seite erhält, generieren diese Konfigurationen eine lokale Besucher-ID.
Anwendungsfall 2: Anfordern einer ID von einem iFrame, der in eine übergeordnete Seite eingebettet ist, die Sie nicht steuern oder die den Besucher-ID-Service nicht verwendet
Dieses Nutzungsszenario schließt die folgenden Bedingungen ein:
- Unternehmen A verwendet nicht den Besucher-ID-Service.
- 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 hat der Besucher-ID-Dienst folgende Möglichkeiten:
- Funktioniert nicht im iFrame. Dies liegt daran, dass der Browser den iFrame als Domain eines Drittanbieters betrachtet und den Besucher-ID-Service 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.
Mit diesen Konfigurationen für die weiße Liste können Sie den Besucher-ID-Dienst die Funktion Visitor.getInstance im iFrame ändern. Geben Sie die übergeordneten und untergeordneten Domänen im Code an. Mit diesen Konfigurationen kann der Besucher-ID-Dienst-Code im iFrame den Besucher-ID-Dienst-Code auf der übergeordneten Seite auf eine Besucher-ID überprüfen.
Wenn der Besucher-ID-Dienst-Code im iFrame keine übergeordnete 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 Besucher-ID-Dienst und die iFrame-Domain müssen dieselbe IMS-Organisations-ID verwenden. Diese Konfigurationen der weißen Liste funktionieren nicht, wenn sich die IMS-Organisations-IDs für das übergeordnete Element oder den iFrame unterscheiden.
- 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 Besucher-ID-Dienst auf der übergeordneten Seite keine Anfrage im erwarteten Format erhält, schlägt dieser Freigabeprozess fehl.
Unterstützte Besucher-API-Methoden section-30c6a9f4dcdc4265a1149260b97cc057
Der Besucher-ID-Dienst unterstützt eine begrenzte Anzahl öffentlicher API-Methoden, wenn Sie diese Konfigurationen für die weiße Liste implementieren. Die unterstützten Methoden variieren je nach den oben beschriebenen Nutzungsszenarios.
- getMarketingCloudID
- getAudienceManagerLocationHint
- getAudienceManagerBlob
- getSupplementalDataID
- getCustomerIDs
- getSupplementalDataID
- getMarketingCloudVisitorID