Ja, Fullstory funktioniert problemlos mit den meisten Iframes! Abhängig von deinem Szenario kann die Erfassung von Iframe-Inhalten eine zusätzliche Konfiguration erfordern. Dieser Artikel behandelt gängige Implementierungsszenarien sowie einige Dinge, die bei der Arbeit mit Iframes zu beachten sind.
Unterstützung gängiger Iframe-Implementierungsszenarien
Diese Tabelle beschreibt die Unterstützung gängiger Iframe-Implementierungsszenarien. In den folgenden Szenarien bezieht sich „äußere Seite“ auf die oberste HTML-Seite, die nicht in einem iFrame oder window.top
läuft. Lies weiter, um detailliertere Informationen zu den einzelnen Szenarien zu erhalten.
Szenario der Implementierung |
Beispiel |
Unterstützung |
1) Auf der äußeren Seite läuft Fullstory und dein Iframe läuft auf derselben Domain. |
Eine Single-Domain-Site, die Iframes verwendet, um verschiedene Komponenten zu organisieren. |
|
2) Auf der äußeren Seite läuft Fullstory und dein Iframe läuft auf einer anderen Domain. |
Eine Website mit gemischten Domänen, die Iframes verwendet, um verschiedene Komponenten zu organisieren. |
|
3) Auf der äußeren Seite läuft nicht Fullstory und du möchtest eine Seite erfassen, die in einem Iframe ausgeführt wird. |
dein Inhalt ist in eine Website eines Drittanbieters eingebettet, die Fullstory nicht verwendet. |
|
4) Du möchtest eine Seite erfassen, die in einem Iframe ausgeführt wird, aber die äußere Seite erfasst Daten in einem anderen Fullstory-Konto. |
dein Inhalt ist in eine Website eines Drittanbieters eingebettet, aber diese Seite verwendet auch Fullstory. |
|
5) Auf der äußeren Seite läuft Fullstory, aber Du hast keinen Zugriff auf den Quellcode des iframed-Inhalts. |
Ein Support-Widget eines Drittanbieters, das in deine Website eingebettet ist. |
1) Auf der äußeren Seite läuft Fullstory und all deine Iframes laufen auf derselben Domain.
Zum Beispiel betreibst du eine Single-Domain-Site und verwendest Iframes, um verschiedene Komponenten zu organisieren.
Was musst du tun: Du musst nichts Besonderes tun.Führe Fullstory auf der äußeren Seite aus, und alles sollte aufgenommen werden. Wenn du auch das Fullstory-Datenerfassungs-Snippet in deinen Iframes hast, ist das auch in Ordnung. Das Datenerfassungsskript innerhalb der Iframes wird automatisch auf die äußere Seite verschoben.
Hinweis: Falls der Iframe derselben Herkunft (gleiche Domäne) leer ist, wenn fs.js auf der Hauptseite ausgeführt wird, fügt sich Fullstory nicht selbst in diesen Frame ein und er wird nicht erfasst.
2) Auf der äußeren Seite läuft Fullstory und Du hast Iframes, die auf einer anderen Domain laufen.
WICHTIGER SICHERHEITSHINWEIS:
Bevor du das Fenster ['_fs_run_in_iframe']
konfigurierst, solltest du die Auswirkungen auf die Sicherheit verstehen und deine Content Security Policy (CSP) -HTTP-Header entsprechend konfigurieren, insbesondere die Frame-Ancestor-Direktive
.
Wenn du deine CSP-Header nicht konfigurierst, während du diese Einstellung verwendest, kann dies den Iframe-Sicherheitsschutz umgehen, der in modernen Browsern enthalten ist. Wenn du dir nicht sicher bist, was das bedeutet, kontaktiere uns erbitte weitere Informationen, bevor du fortfährst.
Dieser Fall gilt, wenn du eine Website mit gemischten Domänen hast, die Iframes verwendet, aber logischerweise ist alles Teil einer einzigen Anwendung und du möchtest, dass alles zusammen erfasst wird. (Hinweis: Klicke hier für eine detaillierte Erklärung dessen, was „herkunftsübergreifend” bedeutet. Zum Beispiel würde ein Iframe aus der Subdomain.example.com, der auf beispiel.com erscheint, als Site-Umgebung mit gemischten Domänen betrachtet werden.)
Was musst du tun: Um Inhalte der äußeren Seite zu erfassen, lege das standardmäßige Fullstory-Datenerfassungs-Snippet auf die äußere Seite. Um den iFrame-Inhalt zu erfassen, füge dieses spezielle Flag zum Fullstory-Datenerfassungsausschnitt hinzu und platziere es auf der Seite, auf der der IFrame gehostet wird (sowie innerhalb des IFrames selbst):
window['_fs_run_in_iframe'] = true; //Whoa! Gehe vorsichtig vor. Bevor du diese neue Variable innerhalb des IFrames hinzufügst, solltest du dich vor den Auswirkungen auf die Sicherheit hüten und deine CSP-Header entsprechend konfigurieren. Weitere Informationen findest du in den Sicherheitshinweisen oben.
Das resultierende Iframe-Skript sollte also mit window ['_fs_run_in_iframe'] beginnen.
= wahr;
als erste Zeile deines standardmäßigen Fullstory-Datenerfassungsausschnitts.
Das _fs_run_in_iframe-Flag teilt Fullstory mit, dass der Iframe sich selbst erfassen und mit der äußeren Seite kommunizieren sollte, auf der auch Fullstory läuft, sodass sie zusammen in einem einzigen Capture angezeigt werden. Nochmals, das ist nur notwendig, wenn der IFrame in Bezug auf die äußere Seite herkunftsübergreifend ist.
Hinweis: Wenn du einen Iframe erfassen möchtest, bei dem die Sandbox
-Eigenschaft gesetzt ist, musst du auch allow-same origin
zur Sandbox-Eigenschaft
hinzufügen, sonst kann Fullstory den Inhalt des iframe nicht erfassen.
3) Auf der äußeren Seite wird Fullstory nicht ausgeführt und du möchtest eine Seite erfassen, die in einem Iframe ausgeführt wird.
Zum Beispiel stelle Inhalte in einem IFrame bereit, der in eine Website eines Drittanbieters eingebettet ist, die Fullstory nicht verwendet.
Was musst du tun: Füge innerhalb des IFrames das übliche Fullstory-Datenerfassungs-Snippet hinzu und füge dem Skript dieses spezielle Flag hinzu:
window ['_fs_is_outer_script'] = wahr;
Das resultierende Iframe-Skript wird also ungefähr so aussehen:
window ['_fs_is_outer_script'] = true; // <-- hier ist die neue Variable zum Hinzufügen, nur innerhalb des IFrames
window ['_fs_debug'] = falsch;
window ['_fs_host'] = 'www.fullstory.com';
(usw...)
Das _fs_is_outer_script-Flag teilt Fullstory mit, dass der Iframe die „Wurzel” der erfassten Daten ist und eine eigene Sitzung sein sollte.
4) Du möchtest eine Seite, die in einem Iframe ausgeführt wird, in deinem Fullstory-Konto erfassen, aber die äußere Seite erfasst Daten in einem anderen Fullstory-Konto.
Zum Beispiel, vielleicht stellst du Inhalte in einem Iframe bereit und sie sind in eine Website eines Drittanbieters eingebettet, die zufällig auch Fullstory verwendet, aber sie haben ihr eigenes Fullstory-Konto, das sich von deinem unterscheidet.
Was musst du tun: Folge den Anweisungen aus Teil 3 und verwende das _fs_is_outer_script-Flag innerhalb des IFrames. Die äußere Seite wird sich selbst in einem Fullstory-Konto erfassen, wodurch der Iframe als leeres Feld dargestellt wird. Der Iframe wird sich selbst in einem anderen Fullstory-Konto erfassen und alles, was du sehen wirst, ist der Iframe selbst, nicht der Inhalt um ihn herum. In diesem Szenario gibt es keine Möglichkeit, den gesamten Inhalt zusammen zu sehen.
5) Auf der äußeren Seite läuft Fullstory, aber du hast keinen Zugriff auf den Quellcode des Iframe-Inhalts.
Wenn du Inhalte in einem Iframe hast, für die du keinen Zugriff auf den Quellcode hast, kannst du den Inhalt dieses IFrames nicht erfassen. Ein Beispiel dafür könnte ein Support-Widget eines Drittanbieters sein, das in deine Website eingebettet ist. Wenn du nicht in der Lage bist, dein Fullstory-Datenerfassungs-Snippet zum Inhalt der Iframe-Seite hinzuzufügen, ist es nicht möglich, den Iframe-Inhalt für die Sitzungswiedergabe zu erfassen.
Arbeiten mit Iframes und Fullstory
Es gibt einige Möglichkeiten, wie sich Fullstory anders oder vielleicht unerwartet verhält, wenn du mit Iframes arbeitest.
Eingeschränkte Unterstützung für die Fullstory JavaScript-API innerhalb von Iframes
Die einzige Fullstory JavaScript-API-Methode, die in Iframes unterstützt wird, ist die FS.Event-API.Aufrufe anderer JS-API-Methoden innerhalb von Iframes haben ein undefiniertes Verhalten.
Eingebettete Iframes verwenden
Wenn du Fullstory verwendest, um Seiten mit eingebetteten Iframes zu erfassen, und postMessage ()
auch verwendest, um über Frames hinweg zu kommunizieren, siehst du möglicherweise unerwartete Nachrichten in deinem Message-Ereignishandler.
Fullstory muss die PostMessageAPI verwenden, um Capture-Daten von Frames bis zum übergeordneten Fenster zu übertragen, da sich diese Frames auf verschiedenen Domänen befinden können.
Leider hat dieser Kommunikationsmechanismus insofern einen Konstruktionsfehler, als es keine formale Methode gibt, Skripte zu benennen. Also werden mehrere Skripte, die über diesen Kanal kommunizieren, die Nachrichten der anderen empfangen und müssen einen Weg finden, diejenigen auszuschließen, die nicht dafür bestimmt sind.
Falls ein anderes Skript auf der Seite die empfangenen Nachrichten nicht ausdrücklich testet, kann es Ausnahmen oder andere Fehler anzeigen. Das Folgende ist ein Beispiel für einen solchen Fall:
Window.addEventListener ('Nachricht', Funktion (e) {
var msg = JSON.parse(e.data);
doSomethingWith(msg.someField);
}, falsch);
Der obige Code löst eine Ausnahme aus, wenn er versucht, auf msg.SomeField
zuzugreifen.
Die Ausnahme ist harmlos, erzeugt aber Fehlermeldungen auf der Javascript-Konsole. Der beste Ansatz ist, sich mit einem einfachen Test vor diesem Fall zu schützen, zum Beispiel:
Window.addEventListener ('Nachricht', Funktion (e) {
Von msg;
//Stelle außerdem sicher, dass die JSON-Analyse nicht fehlschlägt, denn e.data könnte Text sein.
Versuche es mit { msg = JSON.parse(e.data); } catch (e) { }
// Stelle sicher, dass diese Nachricht tatsächlich für uns bestimmt war.
if ('SomeField' in msg) {
doSomethingWith(msg.someField);
}
}, falsch);
Wenn du dich auf diese Weise an Nachrichtenhandler wendest, wird sichergestellt, dass sie nicht nur gegenüber unerwarteten Nachrichten von fs.js, sondern auch gegenüber allen anderen Skripten, die postMessage ()
verwenden, um über Frames hinweg zu kommunizieren