Show Menu
TOPICS×

whitelistParentDomain und whitelistIframeDomains

Diese Konfigurationen ermöglichen die Kommunikation zwischen verschiedenen Instanzen von ID-Dienstcode, die in einem iFrame implementiert sind, und solchen, die in die übergeordnete Seite implementiert sind. Sie sollen dabei helfen, Probleme in zwei konkreten Nutzungsszenarios zu lösen, in denen Sie die übergeordnete Seite/Domäne verwalten oder auch nicht und bei denen ID-Dienstcode im iFrame einer von Ihnen verwalteten Domäne geladen wird. Sie sind in VisitorAPI.js ab Codeversion 2.2 verfügbar.
Inhalt:

Syntax

Beide Konfigurationselemente sind erforderlich, wenn Sie diesen Code verwenden.
Konfigurationssyntax
Beschreibung
whitelistParentDomain: "
Domänenname der übergeordneten Seite
"
Akzeptiert einen einzelnen Domänennamen, der als Zeichenfolge übergeben wird.
whitelistIframeDomains: [
"iFrame Domain", "iFrame Domain", "iFrame Domain"
]
Akzeptiert einen oder mehrere iFrame-Domänennamen, die als Array übergeben werden.

Codebeispiel

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

Nutzungsszenarios

Wenn Sie einen ID-Dienst-Cookie setzen und eine Besucher-ID zuweisen möchten, der Browser jedoch Drittanbieter-Cookies blockiert, können Sie das Problem mit diesen Konfigurationen lösen. Allerdings muss dazu eine der beiden folgenden Bedingungen erfüllt sein:
  • Sie verwalten die übergeordnete Seite/Domäne oder auch nicht.
  • Der ID-Dienstcode ist auf der übergeordneten Seite nicht installiert, jedoch in einem iFrame implementiert.
You may also want to implement these configurations when you're serving video in an iFrame with Video Heartbeat . Zur ordnungsgemäßen Funktionsweise benötigt Video Heartbeat eine vom ID-Dienst bereitgestellte ID (die MID).
Nutzungsszenario 1: Der Browser blockiert Drittanbieter-Cookies und der ID-Dienst ist auf dem iFrame und der übergeordneten Seite implementiert
Element des Nutzungsszenarios
Beschreibung
Bedingungen
Dieses Nutzungsszenario beinhaltet die folgenden Bedingungen:
  • Unternehmen A implementiert den ID-Dienst auf seiner Homepage.
  • Unternehmen A implementiert den ID-Dienst in iFrame auf seiner Homepage.
  • Unternehmen A gehören die übergeordnete Seite und der iFrame. Das Unternehmen hat den ID-Dienst an beiden Stellen implementiert.
  • Ein Kunde lädt die übergeordnete Seite in einen Browser, der Drittanbieter-Cookies blockiert.
Ergebnisse
Unter diesen Bedingungen verhält sich der ID-Dienst wie folgt:
  • Er funktioniert ordnungsgemäß auf der übergeordneten Seite. Er fordert AMCV-Cookies an und weist dem Site-Besucher eine eindeutige ID zu.
  • Er funktioniert nicht im iFrame. Der Grund ist, dass der Browser den iFrame als Drittanbieterdomäne betrachtet und den ID-Dienst daran hindert, den AMCV-Cookie zu setzen.
Lösung
Ä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-Dienstcode im iFrame eine Besucher-ID im ID-Dienstcode der übergeordneten Seite suchen.
Wenn der ID-Dienstcode im iFrame keine Antwort von der übergeordneten Seite erhält, wird mit diesen Konfigurationen eine lokale Besucher-ID generiert.
Nutzungsszenario 2: Eine ID wird von einem iFrame angefordert, der in eine übergeordnete Seite eingebettet ist, über die Sie keine Kontrolle haben oder die den ID-Dienst nicht verwendet
Element des Nutzungsszenarios
Beschreibung
Bedingungen
Dieses Nutzungsszenario beinhaltet die folgenden Bedingungen:
  • Unternehmen A verwendet den ID-Dienst nicht.
  • Unternehmen A lädt einen iFrame auf der Seite. Dieser iFrame gehört Unternehmen B und wird in einer anderen Domäne als derjenigen von Unternehmen A geladen.
  • Der Browser blockiert Drittanbieter-Cookies.
Ergebnisse
Unter diesen Bedingungen verhält sich der ID-Dienst wie folgt:
  • Er funktioniert nicht im iFrame. Der Grund ist, dass der Browser den iFrame als Drittanbieterdomäne betrachtet und den ID-Dienst daran hindert, den AMCV-Cookie zu setzen.
  • Es kann keine Besucher-ID von der übergeordneten Seite abgerufen werden, da Unternehmen A diesen Dienst nicht verwendet.
Lösung
Ä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-Dienstcode im iFrame eine Besucher-ID im ID-Dienstcode der übergeordneten Seite suchen.
Wenn der ID-Dienstcode im iFrame keine Antwort von der übergeordneten Seite erhält, wird mit diesen Konfigurationen eine lokale Besucher-ID generiert.

Sicherheit der Konfiguration

Aus folgenden Gründen können Sie diese Konfigurationen sicher implementieren:
  • Der in der übergeordneten Domäne implementierte ID-Dienst und die iFrame-Domäne müssen die gleiche Organisations-ID verwenden. Diese Whitelist-Konfigurationen funktionieren nicht, wenn sich die Organisations-IDs in der übergeordneten Domäne oder im iFrame unterscheiden.
  • Diese Konfigurationen können nur mit der Domäne und den iFrames kommunizieren, die im Code angegeben sind.
  • Die Kommunikation zwischen iFrame und übergeordneter Seite erfolgt in einem spezifischen Format. Wenn der ID-Dienst auf der übergeordneten Seite keine Anforderung im erwarteten Format erhält, schlägt dieser Kommunikationsvorgang fehl.

Unterstützte Besucher-API-Methoden

Der ID-Dienst unterstützt eine beschränkte Anzahl öffentlicher API-Methoden, wenn diese Whitelist-Konfigurationen implementiert werden. Die unterstützten Methoden sind je nach Nutzungsszenario (siehe Beschreibung oben) unterschiedlich.
Anwendungsfall
Unterstützte Methoden
1. Fall
  • getMarketingCloudID
  • getAudienceManagerLocationHint
  • getAudienceManagerBlob
  • getSupplementalDataID
  • getCustomerIDs
2. Fall
  • getSupplementalDataID
  • getMarketingCloudVisitorID