whitelistParentDomain und 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/Domäne verwalten oder auch nicht und bei denen ID-Dienstcode im iFrame einer von Ihnen verwalteten Domäne geladen wird. Sie sind in Version 2.2 (oder höher) des VisitorAPI.js-Codes 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"], 
 ... 
 } 
);

Anwendungsfälle

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/Domäne oder steuern sie nicht.
  • Der ID-Dienst-Code wird nicht auf der übergeordneten Seite installiert, sondern in einem iFrame implementiert.
TIPP

Sie können diese Konfigurationen auch implementieren, wenn Sie Videos in einem iFrame mit Video Heartbeat bereitstellen. 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 wird auf der iFrame- und der übergeordneten Seite implementiert

Nutzungsszenario Beschreibung

Bedingungen

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.

Ergebnisse

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.

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-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

Nutzungsszenario Beschreibung

Bedingungen

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 Domäne als Firma A geladen.
  • Der Browser blockiert Drittanbieter-Cookies.

Ergebnisse

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 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-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

Sie können diese Konfigurationen aus folgenden Gründen sicher implementieren:

  • Der in der übergeordneten Domäne 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 Domäne 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

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.

Anwendungsfall Unterstützte Methoden

1. Fall

  • getMarketingCloudID
  • getAudienceManagerLocationHint
  • getAudienceManagerBlob
  • getSupplementalDataID
  • getCustomerIDs

2. Fall

  • getSupplementalDataID
  • getMarketingCloudVisitorID

Auf dieser Seite