Signierte Einbettung

Hinweis: Wenn Sie eine Looker (Google Cloud Core)-Instanz verwenden, müssen Sie die Embed-Version von Looker (Google Cloud Core) verwenden, um die signierte Einbettung zu aktivieren. Wenn Sie eine Looker-Instanz (Original) verwenden, muss die signierte Einbettung für Ihre Instanz aktiviert sein. Wenden Sie sich an einen Vertriebsspezialisten von Google Cloud , um diese Funktion aktivieren zu lassen.

Mit der signierten Einbettung können Sie Ihren Nutzern private eingebettete Looks, Visualisierungen, Explores, Dashboards oder LookML-Dashboards präsentieren, ohne dass sie einen separaten Looker-Log-in benötigen. Stattdessen werden Nutzer über Ihre eigene Anwendung authentifiziert.

Bei der signierten Einbettung wird eine spezielle Looker-URL erstellt, die Sie in einem iFrame verwenden. Die URL enthält die Informationen, die Sie freigeben möchten, die ID des Nutzers in Ihrem System und die Berechtigungen, die der Nutzer haben soll. Anschließend signieren Sie die URL mit einem von Looker bereitgestellten Secret-Schlüssel.

Informationen zur öffentlichen Einbettung finden Sie im Abschnitt Öffentliche Einbettung mit iframe-Tags auf der Dokumentationsseite Öffentliche Freigabe, Import und Einbettung von Looks.

Bevor Sie die signierte Einbettung in Ihrer Looker-Instanz verwenden können, muss ein Looker-Administrator die signierte Einbettung im Admin-Bereich von Looker aktivieren und einen geheimen Einbettungsschlüssel erstellen. Eine Anleitung finden Sie auf der Dokumentationsseite Erste Schritte mit der Einbettung – Signierte Einbettung aktivieren.

Geeignetes Hosting für signierte Einbettungen

In einigen Browsern, z. B. Safari, oder in Browsern mit installierten Erweiterungen, die Anzeigen oder Tracking-Cookies blockieren, werden Drittanbieter-Cookies standardmäßig blockiert. Wenn die Funktion Cookieless Embed aktiviert ist, können Browser, die Drittanbieter-Cookies blockieren, Nutzer im eingebetteten iFrame über verschiedene Domains hinweg authentifizieren. Die cookielose Einbettungsauthentifizierung erfordert eine serverseitige Konfiguration. Beispiele für die Einrichtung finden Sie auf der Dokumentationsseite Cookielose Einbettung.

Hinweis: Eine Liste der von Looker verwendeten Cookies finden Sie auf der Dokumentationsseite Looker-Cookie-Liste.

Wenn die Funktion Cookieless Embed nicht aktiviert ist, verwendet Looker Cookies für die Nutzerauthentifizierung. In diesem Fall ist es in Browsern, die Drittanbieter-Cookies blockieren, nicht möglich, den eingebetteten iFrame domainübergreifend zu authentifizieren, es sei denn, der Nutzer ändert die Cookie-Datenschutzeinstellungen seines Browsers. Wenn Sie beispielsweise Informationen auf https://mycompany.com einbetten möchten, müssen Sie dafür sorgen, dass Looker dieselbe Domain verwendet, z. B. https://analytics.mycompany.com. Wenn Looker Ihre Instanz hostet, wenden Sie sich an den Looker-Support, um die erforderliche DNS-Konfiguration für die Verwendung einer benutzerdefinierten Domain einzurichten. Dadurch kann Looker dieselbe Domain wie die eingebettete Anwendung verwenden und eigene Cookies nutzen, die standardmäßig in allen Browsern akzeptiert werden.

Wenn Sie eine vom Kunden gehostete Looker-Instanz haben, achten Sie darauf, dass die Anwendung, die die signierte Einbettung verwendet, dieselbe Domain wie Ihre Looker-Instanz verwendet.

Clientsichtbarkeit mit einem geschlossenen System steuern

In einer signierten Einbettungskonfiguration ist es üblich, dass Looker-Nutzer ihren eigenen Kunden Daten präsentieren, während sie Kunden aus verschiedenen Unternehmen oder Gruppen haben, die nichts voneinander wissen sollen. In diesem Szenario empfehlen wir dringend, Looker als geschlossenes System zu konfigurieren, auch als Mehrmandanteninstallation bezeichnet, um die privaten Informationen Ihrer Kunden zu schützen. In einem geschlossenen System werden Inhalte in Silos zusammengefasst, um zu verhindern, dass sich Benutzer aus verschiedenen Gruppen untereinander kennen. Daher empfehlen wir, die Option Geschlossenes System zu aktivieren, bevor Sie externen Nutzern Zugriff auf Ihre Instanz gewähren.

Weitere Informationen finden Sie auf den Dokumentationsseiten System von Zugriffsebenen entwerfen und konfigurieren und Best Practices für die Sicherheit eingebetteter Analysen.

Signierte Einbettungs-URL generieren

Es gibt mehrere Möglichkeiten, die signierte Einbettungs-URL zu generieren. Sie haben dazu folgende Möglichkeiten:

• Sie können eine signierte Einbettungs-URL generieren, indem Sie im Dreipunkt-Menü eines Dashboards oder im Zahnradmenü für Explore-Aktionen eines Looks oder Explores die Option Einbettungs-URL abrufen auswählen.

• Verwenden Sie den Looker API-Endpunkt „Create Signed Embed Url“, wie weiter unten in diesem Dokument beschrieben.

• Verwenden Sie das Looker Embed SDK.

• Signierte Einbettungs-URL codieren Zum Erstellen der richtigen URL müssen Sie Code schreiben, damit Sie die URL mit Ihrem Secret-Schlüssel richtig codieren und andere sicherheitsrelevante Elemente generieren können. Im GitHub-Repository für Looker-Einbettungsbeispiele finden Sie mehrere Beispielskripts. In den folgenden Abschnitten werden die Informationen erläutert, die Sie für diese Skripts angeben müssen, und wie Sie eine signierte Einbettungs-URL ohne Skript erstellen.

Hinweis: Pro Browser ist nur eine Nutzersitzung möglich. Während der Entwicklung können Sie sich in Ihrem regulären Browser als Administrator oder Entwickler anmelden. Wenn Sie eine signierte Einbettungskonfiguration testen möchten, können Sie ein Inkognitofenster oder einen anderen Browser verwenden. Andernfalls wird der ursprüngliche Nutzer von der ursprünglichen Sitzung abgemeldet. Wenn auf Ihrer Seite mehrere Looker-iFrames eingebettet sind, lesen Sie die Best Practices für das Einbetten mehrerer iFrames mit signierter Einbettung.

Signierte Einbettungs-URL manuell codieren

Um die signierte Einbettungs-URL zu codieren, müssen Sie zuerst die erforderlichen Looker-Informationen erfassen und dann die signierte Einbettungs-URL erstellen.

Erforderliche Looker-Informationen erfassen

Als Ausgangspunkt für die Erstellung Ihrer URL sollten Sie zuerst alle Informationen festlegen, die enthalten sein müssen. Folgendes wird benötigt:

URL einbetten

Rufen Sie die URL des Looks, Explores, der Abfragevisualisierung oder des Dashboards ab, das Sie einbetten möchten. Entfernen Sie dann die Domain und fügen Sie /embed vor dem Pfad ein:

Element	Normales URL-Muster	URL einbetten
Look	https://instance_name.looker.com/looks/4	/embed/looks/4
Erkunden	https://instance_name.looker.com/explore/my_model/my_explore	/embed/explore/my_model/my_explore
Abfragevisualisierung	https://instance_name.looker.com/explore/my_model/my_explore?qid=1234567890abcdefghij12 Die 22 alphanumerischen Zeichen, die auf den Parameter qid= in der Explore-URL folgen, bilden die Query.client_id. Der Wert Query.client_id ist ein eindeutiger String, der die Abfrage und die Visualisierungseinstellungen darstellt. Wenn Sie eine Abfragevisualisierung einbetten möchten, rufen Sie den Query.client_id-Wert der Abfragevisualisierung ab und kopieren Sie den Query.client_id-Wert in Ihre Einbettungs-URL. Sie können die Looker-Benutzeroberfläche Explore verwenden, um eine Abfrage mit einer unterstützten Visualisierung zu erstellen und den Wert Query.client_id aus dem Parameter qid= zu kopieren. Alternativ können Sie die Query.client_id mit der Looker API abrufen, z. B. mit der Methode Get Query.	/embed/query-visualization/Query.client_id
Benutzerdefiniertes Dashboard	https://instance_name.looker.com/dashboards/1 Alle Dashboard-Filterwerte, einschließlich ausgeblendeter Filterwerte, also den Parameter hide_filter in der Dashboard-URL.	/embed/dashboards/1
LookML-Dashboard	https://instance_name.looker.com/dashboards/my_model::my_dashboard	/embed/dashboards/my_model::my_dashboard
Konversationelle Analyse	Für die Konversationsseite: https://instance_name.looker.com/conversations Für die Seite „KI-Agenten“: https://instance_name.looker.com/agents Für eine bestimmte Unterhaltung: https://instance_name.looker.com/conversations/conversation_id Weitere Informationen finden Sie auf der Dokumentationsseite Konversationsanalysen einbetten.	/embed/conversations /embed/agents /embed/conversations/c9f370ac830b4669aeb494396422004c

Wichtig: Eingebetteter Inhalt spiegelt immer die Produktionsversion des Inhalts wider. Änderungen, die im Entwicklungsmodus vorgenommen werden, sich auf Inhalte auswirken und nicht in der Produktion bereitgestellt wurden, werden nicht in einer Einbettung angezeigt.

Berechtigungen

Ein Berechtigungssatz definiert, was ein Nutzer oder eine Gruppe tun kann. Berechtigungen können auf zwei Arten angewendet werden:

• Modellspezifisch:Dieser Berechtigungstyp wird nur auf die Modellsätze angewendet, die Teil derselben Rolle sind.
• Instanzweit: Diese Art von Berechtigung gilt für die gesamte Looker-Instanz. Eingebettete Nutzer mit instanzweiten Berechtigungen können bestimmte Funktionen in der gesamten Looker-Instanz ausführen, aber nicht auf Inhalte zugreifen, die auf Modellen basieren, die nicht im Modellset ihrer Rolle enthalten sind.

Legen Sie die Berechtigungen fest, die der Nutzer haben soll. In der folgenden Liste sind alle verfügbaren Berechtigungen für die signierte Einbettung aufgeführt. Berechtigungen, die nicht in der folgenden Liste aufgeführt sind, werden für die signierte Einbettung nicht unterstützt:

Berechtigung	Abhängig von	Typ	Definition
access_data	Keine	Modellspezifisch	Ermöglicht dem Benutzer den Zugriff auf Daten (erforderlich zum Anzeigen von Looks, Dashboards oder Explores)
see_lookml_dashboards	access_data	Modellspezifisch	Nutzer können LookML-Dashboards sehen. Diese Berechtigung ist auch dann erforderlich, wenn ein Nutzer Lesezugriff auf den Ordner des Dashboards hat.
see_looks	access_data	Modellspezifisch	Ermöglicht Nutzern, Looks anzusehen
see_user_dashboards	see_looks	Modellspezifisch	Ermöglicht es Nutzern, benutzerdefinierte Dashboards aufzurufen und Ordner über eine Einbettung zu durchsuchen.
explore	see_looks	Modellspezifisch	Nutzer können die Explore-Seiten sehen
create_table_calculations	explore	Instanzweit	Erforderlich, um Tabellenkalkulationen in einem Explore zu erstellen
create_custom_fields	explore	Instanzweit	Erforderlich, um benutzerdefinierte Felder in einem Explore zu erstellen
can_create_forecast	explore	Instanzweit	Ermöglicht Nutzern, Prognosen in Visualisierungen zu erstellen oder zu bearbeiten.
save_content	see_looks	Instanzweit	Ermöglicht dem Benutzer, Änderungen an Looks und Dashboards vorzunehmen und zu speichern
send_outgoing_webhook	see_looks	Modellspezifisch	Ermöglicht es Nutzern, die Inhaltsübermittlung von Looker an einen beliebigen Webhook zu planen
send_to_s3	see_looks	Modellspezifisch	Ermöglicht Nutzern, die Inhaltsübermittlung von Looker an einen Amazon S3-Bucket zu planen
send_to_sftp	see_looks	Modellspezifisch	Ermöglicht es Nutzern, die Inhaltsübermittlung von Looker an einen SFTP-Server zu planen
schedule_look_emails	see_looks	Modellspezifisch	Ermöglicht es Nutzern, die Inhaltsübermittlung von Looker an ihre eigene E-Mail-Adresse (wenn mit einem Nutzerattribut namens „email“ festgelegt) oder an eine E-Mail-Adresse zu planen, die den Einschränkungen der Zulassungsliste für E-Mail-Domains entspricht. Ermöglicht Nutzern mit create_alerts-Berechtigungen, Benachrichtigungen an eine E‑Mail-Adresse zu senden, die den Einschränkungen der Zulassungsliste für E‑Mail-Domains entspricht.
schedule_external_look_emails	schedule_look_emails	Modellspezifisch	Ermöglicht es Nutzern, die Inhaltsübermittlung von Looker an eine beliebige E‑Mail-Domain zu planen. Ermöglicht Nutzern mit der Berechtigung create_alerts, Benachrichtigungen an beliebige E‑Mail-Domains zu senden.
send_to_integration	see_looks	Modellspezifisch	Ermöglicht dem Nutzer, Looker-Inhalte über den Looker Action Hub an die in Looker integrierten Drittanbieterdienste zu senden. Diese Berechtigung steht nicht im Zusammenhang mit Datenaktionen.
schedule_without_limit	see_looks	Modellspezifisch	In 26.4 hinzugefügt In Kombination mit mindestens einer anderen Berechtigung, die es einem Nutzer ermöglicht, Looker-Inhalte zu senden, können Nutzer mit dieser Berechtigung Looks oder Explores senden, die alle Datenzeilen enthalten. Mit dieser Berechtigung wird die Option Alle Ergebnisse im Looker-Planer für Looks und Explores angezeigt.
create_alerts	see_looks	Instanzweit	Ermöglicht es Nutzern, Benachrichtigungen für Dashboard-Tiles zu erstellen, um benachrichtigt zu werden, wenn bestimmte Bedingungen erfüllt oder überschritten werden. Nutzer können ihre eigenen Benachrichtigungen und die öffentlichen Benachrichtigungen anderer Nutzer bearbeiten, duplizieren und löschen. Wenn der Slack-Arbeitsbereich des Nutzers nicht mit der Looker-Instanz verbunden ist, kann der Nutzer keine Benachrichtigungen erstellen, die an Slack gesendet werden.
download_with_limit	see_looks	Instanzweit	Ermöglicht dem Nutzer, die Ergebnisse einer Abfrage mit einem Limit herunterzuladen
download_without_limit	see_looks	Instanzweit	Ermöglicht dem Nutzer, die Ergebnisse einer Abfrage ohne Einschränkung herunterzuladen
see_sql	see_looks	Modellspezifisch	Ermöglicht Nutzern, den SQL-Code für Abfragen und alle SQL-Fehler zu sehen, die beim Ausführen von Abfragen auftreten
clear_cache_refresh	access_data	Modellspezifisch	Nutzer können den Cache leeren und eingebettete Dashboards, ältere Dashboards, Dashboard-Tiles, Looks und Explores aktualisieren.
see_drill_overlay	access_data	Modellspezifisch	Ermöglicht es Nutzern, einen Drilldown durchzuführen, ohne die vollständige Explore-Seite aufrufen zu müssen.
manage_spaces	Keine	Instanzweit	Aktiviert den Inhaltsbrowser, damit Nutzer Ordner erstellen, kopieren, verschieben und löschen können. Nutzer benötigen außerdem die Berechtigung Zugriff verwalten, Bearbeiten für den Zugriff auf Inhalte für den Ordner oder, wenn ein neuer Ordner erstellt wird, für den übergeordneten Ordner.
embed_browse_spaces	Keine	Instanzweit	Aktiviert den Inhaltsbrowser, damit ein Benutzer Ordner aus einer Einbettung durchsuchen kann. Alle eingebetteten Nutzer, denen die Berechtigung embed_browse_spaces gewährt wird, erhalten Zugriff auf einen persönlichen eingebetteten Ordner und auf den Ordner Geteilt Ihrer Organisation, falls vorhanden. Die Berechtigung embed_browse_spaces wird für Nutzer mit der Berechtigung save_content empfohlen, damit sie Ordner durchsuchen können, wenn sie auswählen, wo Inhalte gespeichert werden sollen. Damit der Nutzer die Inhalte in Ordnern sehen kann, benötigt er außerdem die Berechtigungen see_looks, see_user_dashboards und see_lookml_dashboards. Die Berechtigung embed_browse_spaces ist für eingebettete Nutzer erforderlich, die Dashboards oder Looks als Favoriten markieren möchten, da für das Markieren von Inhalten als Favorit Zugriff auf den Ordner Favoriten erforderlich ist.
embed_save_shared_space	Keine	Instanzweit	Ermöglicht Nutzern, die auch die Berechtigung save_content haben, im Dialogfeld Speichern zum Ordner Freigegeben der Organisation zu wechseln, falls vorhanden. Nutzer, die die Berechtigung save_content, aber nicht die Berechtigung embed_save_shared_space haben, können Inhalte nur in ihrem persönlichen Einbettungsordner speichern. Die Berechtigung embed_save_shared_space setzt die Berechtigungen für den Zugriff auf Inhalte nicht außer Kraft. Wenn ein Nutzer beispielsweise im Ordner Freigegeben speichern können soll, benötigt er weiterhin die Berechtigung Zugriff verwalten, Bearbeiten für den Ordner Freigegeben. Darüber hinaus verhindert das Fehlen der Berechtigung embed_save_shared_space nicht, dass ein Nutzer mit der Berechtigung save_content und dem Zugriff Zugriff verwalten, Bearbeiten auf den Ordner Freigegeben dort Inhalte speichert, wenn er eine alternative Möglichkeit hat, zum Ordner Freigegeben zu navigieren, z. B. über die Option Von hier aus explorieren in einem eingebetteten Dashboard.
gemini_in_looker	Keine	Modellspezifisch	Diese Berechtigung ist die einzige Berechtigung, die in der Standardrolle für Gemini enthalten ist. Mit dieser Berechtigung können Nutzer die Aufgaben ausführen, die mit den Gemini in Looker-Funktionen verknüpft sind, die auf der Seite Gemini in Looker im Admin-Bereich aktiviert sind. Für einige Aufgaben sind möglicherweise zusätzliche Berechtigungen erforderlich.
chat_with_agent	gemini_in_looker	Modellspezifisch	Hinzugefügt in 25.18 Nutzer von Conversational Analytics können mit KI-Datenagenten chatten, die auf den Daten von bis zu fünf Looker-Explores basieren, oder mit Dashboard-KI-Datenagenten. Für den Chat mit Dashboard-Daten-Agents sind zusätzliche Berechtigungen erforderlich.
chat_with_explore	chat_with_agent	Modellspezifisch	Hinzugefügt in 25.18 Nutzer von konversationellen Analysen können mit einem Looker-Explore chatten, wenn sie auch zusätzliche erforderliche Berechtigungen haben.
save_agents	chat_with_explore	Modellspezifisch	Hinzugefügt in Version 25.18 Nutzer von konversationeller Analyse können Daten-Agents in Dashboards oder Explores erstellen, bearbeiten, löschen und freigeben. Wenn Nutzer einen von einem anderen Nutzer erstellten Daten-KI-Agenten bearbeiten, löschen oder freigeben möchten, muss ihnen eine Rolle zugewiesen werden, die diese Berechtigung für jedes vom Agenten verwendete Modell enthält. Außerdem benötigen sie zusätzliche erforderliche Berechtigungen und Zugriff verwalten, Bearbeitungszugriff für den Agenten.
admin_agents	gemini_in_looker	Modellspezifisch	Hinzugefügt am 25.18 Nutzer können Daten-Agents für die Verwendung mit der Conversational Analytics API und eingebetteter Conversational Analytics erstellen, bearbeiten, freigeben und löschen. Wenn ein Nutzer einen KI-Datenagenten erstellt, erhält er automatisch die Berechtigung Zugriff verwalten, Bearbeiten für den KI-Datenagenten. Mit dieser Berechtigung muss einem Nutzer kein Zugriff auf Inhalte des Daten-Agenten gewährt werden, um einen von einem anderen Nutzer erstellten Daten-Agenten zu bearbeiten, zu löschen oder freizugeben.

Modellzugriff

Legen Sie fest, auf welche LookML-Modelle der Nutzer Zugriff haben soll. Dies ist eine Liste von Modellnamen.

Nutzerattribute

Legen Sie fest, welche Nutzerattribute der Nutzer ggf. haben sollte. Sie benötigen den Namen des Nutzerattributs aus Looker sowie den Wert, den der Nutzer für dieses Attribut haben soll.

Gruppen

Legen Sie fest, welchen Gruppen der Nutzer ggf. angehören soll. Sie benötigen die Gruppen-IDs, nicht die Gruppennamen. Wenn Sie einen Nutzer mit signierter Einbettung einer Looker-Gruppe hinzufügen, können Sie den Zugriff dieses Nutzers auf Looker-Ordner verwalten. Nutzer mit signierter Einbettung haben Zugriff auf alle Ordner, die für Mitglieder ihrer Looker-Gruppen freigegeben sind.

Sie können auch den Parameter external_group_id verwenden, um eine Gruppe zu erstellen, die sich außerhalb der regulären Looker-Gruppen befindet. In diesem Fall haben Nutzer mit signierter Einbettung und demselben external_group_id Zugriff auf einen freigegebenen Ordner namens „Group“, der für die externe Gruppe eindeutig ist.

Hinweis: Der Parameter external_group_id ist die einzige verfügbare Methode zum Erstellen externer Gruppen von eingebetteten Nutzern. Es gibt keine Möglichkeit, externe eingebettete Nutzergruppen über die Looker-Benutzeroberfläche zu konfigurieren.

Nutzer mit signierter Einbettung sind eindeutige, synthetische Nutzer, die von der Einbettungs-URL generiert werden und keine Berechtigungen von extern verwalteten SAML-Gruppen übernehmen können. Wenn Sie einem signierten eingebetteten Nutzer Berechtigungen gewähren möchten, müssen Sie lokal verwaltete Looker-Gruppen verwenden und diese Gruppen-IDs im Parameter group_ids der Einbettungs-URL übergeben. Wenn Sie extern verwaltete SAML-Gruppenberechtigungen in einem eingebetteten iFrame berücksichtigen müssen, verwenden Sie die private Einbettung anstelle der signierten Einbettung. Dadurch kann sich der Nutzer über den standardmäßigen SAML-Anmeldevorgang authentifizieren.

Eingebettete Rollen

Mit den Parametern permissions und models wird eine Rolle für den eingebetteten Nutzer erstellt. Diese Rolle wird auf der Seite Nutzer im Bereich Admin von Looker als „Eingebettete Rolle“ angezeigt. Wenn die Parameter permissions, models und group_ids alle in der Einbettungs-URL angegeben sind, wird die eingebettete Rolle zu allen Rollen hinzugefügt, die den im Parameter group_ids aufgeführten Gruppen bereits zugewiesen sind. Dies entspricht den Standardrollen, da alle Rollen in Looker additiv sind.

Angenommen, Sie haben eine vorhandene Gruppe in Looker mit der Gruppen-ID 1 und diese Gruppe hat bereits die Berechtigung explore für ein Modell mit dem Namen model_one. Sie erstellen eine Einbettungs-URL mit den folgenden Parametern:

• group_ids = ["1"]
• permissions = ["access_data","see_looks"]
• models = ["model_two"]

In diesem Fall übernimmt der eingebettete Nutzer die Berechtigung, die Daten auf model_one anzusehen und zu untersuchen. Die mit den vorherigen Parametern erstellte eingebettete Rolle gewährt außerdem die Berechtigung, die Daten auf model_two anzusehen.

Einbettungs-URL erstellen

Eine signierte Einbettungs-URL hat das folgende Format:

https://HOST/login/embed/EMBED URL?PARAMETERS&signature=SIGNATURE

Host

Der Host ist der Ort, an dem Ihre Looker-Instanz gehostet wird. Beispiel: analytics.mycompany.com. Geben Sie die Portnummer an, wenn Sie die Portweiterleitung nicht aktiviert haben, z. B. analytics.mycompany.com:9999.

URL einbetten

Die Einbettungs-URL wurde zuvor ermittelt. Das Format sieht in etwa so aus:

• /embed/looks/4
• /embed/explore/my_model/my_explore
• /embed/query-visualization/Query.client_id
• /embed/dashboards/1 oder /embed/dashboards-legacy/1
• /embed/dashboards/my_model::my_dashboard oder /embed/dashboards-legacy/my_model::my_dashboard

Das bedeutet, dass das Muster /embed//embed/ in Ihrer finalen URL angezeigt wird. Das ist so vorgesehen.

Wenn Sie eingebettete JavaScript-Ereignisse verwenden, müssen Sie den Parameter embed_domain (die Domain, auf der der iFrame verwendet wird) am Ende der Einbettungs-URL hinzufügen, z. B. so:

/embed/looks/4

⇨

/embed/looks/4?embed_domain=https://mywebsite.com

Der Parameter embed_domain wird der Einbettungs-URL vor der URL-Codierung hinzugefügt. Wenn Ihre Einbettungs-URL bereits Suchparameter für Inhalte (z. B. Filterwerte) enthält, hängen Sie den Parameter embed_domain mit einem kaufmännischen Und-Zeichen (&) an:

/embed/looks/4?filter_name=value

⇨

/embed/looks/4?filter_name=value&embed_domain=https://mywebsite.com

Wenn Sie das Embed SDK verwenden, müssen Sie den Parameter embed_domain hinzufügen und sdk=2 am Ende der Einbettungs-URL einfügen, wie hier gezeigt:

/embed/looks/4

⇨

/embed/looks/4?embed_domain=https://mywebsite.com&sdk=2

Mit dem Parameter sdk=2 kann Looker erkennen, dass das SDK vorhanden ist, und zusätzliche Funktionen des SDK nutzen. Das SDK kann diesen Parameter nicht selbst hinzufügen, da er Teil der signierten URL ist.

Wichtig: Die Parameter embed_domain und sdk müssen vor der URL-Codierung direkt an die Einbettungs-URL des Zielinhalts angehängt werden. Fügen Sie embed_domain oder sdk nicht in die Suchparameter der obersten Ebene der /login/embed/-URL oder in die Liste der signierten Parameter ein, die für die Signaturberechnung verwendet wird. Andernfalls wird der Fehler This request includes invalid params: ["embed_domain", "sdk"] ausgegeben.

Parameter

Die folgenden URL-Parameter werden verwendet, um die erforderlichen Informationen für die signierte Einbettung anzugeben:

Parameter	Standardwert	Beschreibung	Datentyp	Beispiel
nonce	Wert erforderlich	Ein beliebiger String, der innerhalb einer Stunde nicht wiederholt werden darf und weniger als 255 Zeichen lang sein muss. So wird verhindert, dass ein Angreifer die URL eines legitimen Nutzers noch einmal sendet, um Informationen zu erhalten, auf die er keinen Zugriff haben sollte.	JSON-String	"22b1ee700ef3dc2f500fb7"
time	Wert erforderlich	Die aktuelle Uhrzeit als UNIX-Zeitstempel.	Ganzzahl	1407876784
session_length	Wert erforderlich	Die Anzahl der Sekunden, die der Nutzer bei Looker angemeldet bleiben soll, zwischen 0 und 2.592.000 Sekunden (30 Tage).	Ganzzahl	86400
external_user_id	Wert erforderlich	Eine Kennung für jeden Nutzer in der Anwendung, in die Looker eingebettet ist. Looker verwendet external_user_id, um signierte eingebettete Nutzer zu unterscheiden. Daher muss jedem Nutzer eine eindeutige ID zugewiesen werden. Sie können für einen Nutzer eine external_user_id mit einem beliebigen String erstellen, solange dieser für den Nutzer eindeutig ist. Jede ID ist mit einer Reihe von Berechtigungen, Nutzerattributen und Modellen verknüpft. Ein einzelner Browser kann jeweils nur eine external_user_id oder Nutzersitzung unterstützen. Die Berechtigungen oder Nutzerattribute eines Nutzers können während einer Sitzung nicht geändert werden. Achten Sie aus Sicherheitsgründen darauf, dass Sie nicht dieselbe external_user_id für verschiedene Einbettungssitzungen für verschiedene interaktive Nutzer verwenden. Achten Sie außerdem darauf, dass Sie nicht dieselbe external_user_id für einen einzelnen Nutzer verwenden, der unterschiedliche Berechtigungen, Nutzerattributwerte oder Modellzugriffe hat. Wenn Sie dieselbe external_user_id für mehrere Nutzer oder für denselben Nutzer mit mehreren Berechtigungen, Nutzerattributen oder Modellsätzen verwenden, können Daten für Nutzer sichtbar sein, die sonst keinen Zugriff darauf hätten.	JSON-String	"user-4"
permissions	Wert erforderlich	Die Liste der Berechtigungen, die der Nutzer haben sollte. Eine Liste der zulässigen Berechtigungen finden Sie im Abschnitt Berechtigungen auf dieser Seite.	Stringarray	[   "access_data",   "see_looks" ]
models	Wert erforderlich	Die Liste der Modellnamen, auf die der Nutzer Zugriff haben soll.	Stringarray	[   "model_one",   "model_two" ]
group_ids	[]	Die Liste der Looker-Gruppen, in denen der Nutzer Mitglied sein soll, falls vorhanden. Verwenden Sie Gruppen-IDs anstelle von Gruppennamen.	Stringarray	["4", "3"]
external_group_id	""	Eine eindeutige Kennung für die Gruppe, zu der der Nutzer in der Anwendung gehört, in die Looker eingebettet ist. Nutzer, die die Berechtigung zum Speichern von Inhalten haben und eine externe Gruppen-ID teilen, können Inhalte in einem freigegebenen Looker-Ordner namens „Group“ speichern und bearbeiten. Der Parameter external_group_id ist die einzige verfügbare Methode zum Erstellen externer Gruppen von eingebetteten Nutzern. Es gibt keine Möglichkeit, externe eingebettete Nutzergruppen über die Looker-Benutzeroberfläche zu konfigurieren. Die Länge von external_group_id darf 81 Zeichen nicht überschreiten. Für die Gruppe wird ein entsprechender Ordner erstellt. Ordnernamen dürfen maximal 100 Zeichen lang sein. Dem Ordnernamen wird „Embed Shared Group“ vorangestellt. Daher ist external_group_id auf 81 Zeichen beschränkt, damit die Zeichenbeschränkung von 100 Zeichen nicht überschritten wird.	JSON-String	"Accounting"
user_attributes	{}	Die Liste der Nutzerattribute, die der Nutzer ggf. haben sollte. Enthält eine Liste von Nutzerattributnamen, gefolgt vom Nutzerattributwert. Wenn Ihr LookML-Modell lokalisiert ist, können Sie das Benutzerattribut locale in der Einbettungs-URL verwenden, um eine Sprache für die Einbettung anzugeben. Wenn Sie beispielsweise den Parameter user_attributes { "locale" : "fr_FR" } einfügen, wird die Einbettung in französischer Sprache geladen.	Hash von Strings	{   "vendor_id" : "17",   "company" : "xactness" }
access_filters	Wert erforderlich	In Looker 3.10 wurde dieser Parameter entfernt, er ist aber weiterhin in der URL erforderlich. Verwenden Sie access_filters mit einem leeren Platzhalter, z. B. access_filters={}.	Leerer Platzhalter	{}
first_name	""	Der Vorname des Nutzers. Wenn Sie das Feld leer lassen, behält first_name den Wert aus der letzten Anfrage bei oder wird auf „Embed“ gesetzt, wenn noch kein Vorname festgelegt wurde.	JSON-String	"Alice"
last_name	""	Der Nachname des Nutzers. Wenn Sie das Feld leer lassen, behält last_name den Wert der letzten Anfrage bei oder wird auf „Embed“ gesetzt, wenn noch kein Nachname festgelegt wurde.	JSON-String	"Jones"
user_timezone	""	Wenn Sie Nutzerspezifische Zeitzonen aktiviert haben, wird der Wert der Option Zeitzone des Betrachters im Drop-down-Menü Zeitzone im eingebetteten Look oder Dashboard festgelegt. Dieser Parameter ändert die Zeitzone, in der der Inhalt angezeigt wird, nicht direkt. Der Nutzer muss eine Zeitzone aus dem Drop-down-Menü auswählen. Gültige Werte finden Sie auf der Dokumentationsseite Referenz für Zeitzonen für signierte Einbettungen. Tipp vom Chat-Team: Wenn Sie möchten, dass eingebettete Inhalte standardmäßig in der Zeitzone des Betrachters angezeigt werden, verwenden Sie eine der folgenden Methoden: Fügen Sie der eingebetteten URL den Parameter ?query_timezone=user_timezone hinzu. Beispiel: /embed/dashboards/1?query_timezone=user_timezone Speichern Sie das eingebettete Dashboard oder den Look mit der Standardzeitzone, die auf Zeitzone des Betrachters festgelegt ist. Dadurch wird standardmäßig die Zeitzone des Nutzers sowohl für eingebettete als auch für nicht eingebettete Nutzer verwendet.	JSON-String oder null	"US/Pacific" – oder – null
force_logout_login	Wert erforderlich	Wenn ein normaler Looker-Benutzer bereits bei Looker angemeldet ist und ein signiertes eingebettetes Element aufruft, können Sie Folgendes auswählen: 1) Sie sollten das Element mit ihren aktuellen Anmeldedaten aufrufen. oder 2) Sie sollten sich abmelden und mit den signierten Einbettungsanmeldedaten wieder anmelden.	Boolesch (wahr oder falsch)	true
ca_chat	true	Wenn Sie konversationelle Analysen und die Einstellung Dashboard-Agenten aktiviert haben, wird hiermit festgelegt, ob der Konversationsbereich des Dashboard-Agenten für eingebettete Nutzer sichtbar ist. Wenn true, ist der Gemini Spark für Nutzer sichtbar, die die entsprechenden Berechtigungen für die Interaktion mit Dashboard-Agenten haben. Gilt nur für eingebettete Dashboards.	Boolesch (wahr oder falsch)	true

Unterschrift

Looker verwendet die Signatur, um zu prüfen, ob das richtige Einbettungs-Secret zum Generieren der Signatur in der Einbettungs-URL verwendet wurde und ob sich die Parameter in der Einbettungs-URL geändert haben. Wenn sich das Einbettungs-Secret oder die URL-Parameter unterscheiden oder geändert haben, stimmt die Signatur nicht überein und die Authentifizierung wird abgelehnt.

Die Signatur in der Einbettungs-URL ist daher ein kryptografisch starker Beweis dafür, dass die Einbettungs-URL während der Übertragung nicht geändert wurde und dass die Einbettungs-URL von einer vertrauenswürdigen Partei erstellt wurde, die im Besitz des geheimen Einbettungsschlüssels ist.

So generieren Sie die Signatur:

1. Erfassen Sie die folgenden Parameterwerte in dieser Reihenfolge:
   • Host, gefolgt von login/embed/ (z. B. analytics.mycompany.com/login/embed/)
   • URL einbetten
   • Nonce
   • Aktuelle Uhrzeit
   • Sitzungsdauer
   • Externe Nutzer-ID
   • Berechtigungen
   • Modelle
   • Gruppen-IDs
   • Externe Gruppen-ID
   • Nutzerattribute
   • Zugriffsfilter (erfordert einen leeren Platzhalter)
   • Sichtbarkeit des Daten-Agents im Dashboard für konversationelle Analysen
2. Alle Werte außer Host und Einbettungs-URL als JSON formatieren
3. Verketten Sie die Werte mit Zeilenumbrüchen (\n):
4. Signieren Sie den verketteten String mit Ihrem geheimen Looker-Einbettungsschlüssel per HMAC-SHA1.

Codierung

Im letzten Schritt müssen Sie die URL codieren.

Vor der Codierung der URL könnte eine korrekt formatierte Einbettungs-URL, die alle möglichen Parameter verwendet, so aussehen:

https://analytics.mycompany.com/login/embed//embed/dashboards/1?
nonce="22b1ee700ef3dc2f500fb7"&
time=1407876784&
session_length=86400&
external_user_id="user-4"&
permissions=["access_data","see_user_dashboards","see_looks"]&
models=["model_one","model_two"]&
group_ids=[4,3]&
external_group_id="Allegra K"&
user_attributes={"vendor_id":"17","company":"xactness"}&
access_filters={}&
ca_chat=false&
first_name="Alice"&
last_name="Jones"&
user_timezone="US/Pacific"&
force_logout_login=true&
signature=123456789ABCDEFGHIJKL

Wie bereits erwähnt, ist es richtig, dass /embed//embed/ in Ihrer URL angezeigt wird.

Nach der Codierung sieht die URL so aus:

https://analytics.mycompany.com/login/embed/%2embed%2Fdashboards%2F1?
nonce=%2222b1ee700ef3dc2f500fb7&%22&
time=1407876784&
session_length=86400&
external_user_id=%22user-4%22&
permissions=%5B%22access_data%22%2C%22see_user_dashboards%22%2C%22see_looks%22%5D&
models=%5B%22model_one%22%2C%22model_two%22%5D&
group_ids=%5B4%2C3%5D&
external_group_id=%22Allegra%20K%22&
user_attributes=%7B%22vendor_id%22%3A%2217%22%2C%22company%22%3A%22xactness%22%7D&
access_filters%7B%7D%26%0A
ca_chat=false&
first_name=%22Alice%22&
last_name=%22Jones%22&
user_timezone=%22US%2FPacific%22&
force_logout_login=true&
signature=123456789ABCDEFGHIJKL

Hinweis: Aus Sicherheitsgründen läuft die Einbettungs-URL ab und funktioniert nicht mehr, wenn innerhalb von fünf Minuten nach ihrer Erstellung keine Verbindung zu ihr hergestellt wird.

API-Endpunkt „Create Signed Embed Url“ verwenden

Die Looker API enthält den Endpunkt Signierte Einbettungs-URL erstellen, der eine Reihe von signierten Einbettungsparametern akzeptiert, einschließlich der URL des Inhalts, den Sie einbetten möchten, und eine vollständige, codierte, kryptografisch signierte URL zurückgibt.

Wenn Sie diesen API-Endpunkt von einem Webserver aus verwenden möchten, muss sich der Webserver mit Administratorberechtigungen bei der Looker API authentifizieren können. Die Webserver-Domain muss auch in der Zulassungsliste für eingebettete Domains aufgeführt sein.

Sie können auch den APIs Explorer verwenden, um eine signierte URL zu generieren, die diesen Endpunkt verwendet. Sie können den API Explorer über den Looker Marketplace auf Ihrer Looker-Instanz installieren. Nachdem die signierte URL generiert wurde, muss sie genau kopiert werden und kann nur einmal verwendet werden. Andernfalls schlägt der Vorgang fehl. Der APIs Explorer ist auch nützlich, um eine signierte URL zu generieren und sie zu Fehlerbehebungszwecken mit einer manuell erstellten signierten URL zu vergleichen.

Weitere Informationen zur Looker API finden Sie auf der Dokumentationsseite Erste Schritte mit der Looker API.

Einbettungs-URL testen

Wenn Sie die finale URL testen möchten, fügen Sie sie im Adminbereich von Looker auf der Seite Einbetten in den URI-Validator für Einbettungen ein. Mit dieser Option können Sie zwar nicht feststellen, ob die von Ihnen vorgesehenen Daten und Berechtigungen richtig eingerichtet wurden, aber Sie können prüfen, ob die Authentifizierung ordnungsgemäß funktioniert.

Best Practices für das Einbetten mehrerer iFrames mit signierter Einbettung

Wenn Sie mehrere Looker-iFrames auf einer einzelnen Seite einbetten, können gleichzeitige Authentifizierungsanfragen für dieselbe external_user_id zu Konflikten bei der Nutzerbereitstellung, Sperrkonflikten auf dem Looker-Server oder abgebrochenen Sitzungen führen. Beachten Sie die folgenden Best Practices, wenn Ihre Anwendung mehrere iFrames einbettet:

• Nur den ersten iFrame mit einer signierten URL authentifizieren: Wenn Sie die signierte Einbettung mit aktivierten Cookies über eine benutzerdefinierte Domain verwenden, sollte nur der erste iFrame auf der Seite eine signierte /login/embed/...-URL laden. Nachfolgende iFrames müssen warten, bis die Authentifizierung des ersten iFrames abgeschlossen ist, und dann unsignierte Einbettungs-URLs (z. B. /embed/dashboards/DASHBOARD_ID) laden, damit sie das Sitzungscookie vom ersten iFrame übernehmen, ohne die Nutzerbereitstellung noch einmal auszuführen. Das Looker Embed SDK (@looker/embed-sdk) übernimmt dies automatisch, nachdem die erste Verbindung hergestellt wurde.

• Iframe vorab laden, um die Sitzung einzurichten: Wenn Sie eine eingebettete Nutzersitzung instanziieren möchten, bevor mehrere Iframes geladen werden, laden Sie einen Iframe mit /embed/preload (oder der Methode .preload() im Embed SDK v2) vorab, um die Sitzung so schnell wie möglich einzurichten.

• In-Frame-Navigation statt Neuerstellung von iFrames verwenden: Wenn Sie das Embed SDK v2 verwenden, können Sie innerhalb eines bereits instanziierten iFrames navigieren, indem Sie Methoden wie connection.loadDashboard(DASHBOARD_ID) oder connection.loadUrl(EMBED_URL) aufrufen, anstatt einen neuen iFrame zu erstellen. Weitere Informationen finden Sie unter Einführung in das Embed SDK.

• Einzelne session_reference_token in der Einbettung ohne Cookies freigeben: Wenn Sie die Einbettung ohne Cookies mit mehreren iFrames auf einer Seite verwenden, lesen Sie die Best Practices für die Einbettung mehrerer iFrames mit der Einbettung ohne Cookies auf der Seite Einbettung ohne Cookies.