Beachten Sie, dass Sie sich gerade die Looker-Dokumentation ansehen. Die Looker Studio-Dokumentation finden Sie unter https://support.google.com/looker-studio.

Diese Seite wurde von der Cloud Translation API übersetzt.

Signierte Einbettung

Mit signierter Einbettung können Sie Ihren Benutzern private eingebettete Looks, Visualisierungen, Explores, Dashboards oder LookML-Dashboards präsentieren, ohne dass diese über eine separate Looker-Anmeldung verfügen müssen. 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 teilen 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 geheimen Schlüssel.

Informationen zum öffentlichen Einbetten finden Sie im Abschnitt Öffentliches Einbetten mit iframe-Tags auf der Dokumentationsseite Öffentliches Teilen, Importieren und Einbetten von Looks.

Bevor Sie signierte Einbettungen in Ihrer Looker-Instanz verwenden können, muss ein Looker-Administrator die signierte Einbettung im Looker-Admin-Steuerfeld aktivieren und einen geheimen Einbettungsschlüssel erstellen. Eine Anleitung dazu findest du auf der Dokumentationsseite Erste Schritte beim Einbetten – Signierte Einbettung aktivieren.

Richtiges Hosting für signierte Einbettung

Einige Browser – z. B. Safari oder Browser mit installierten Erweiterungen, die Anzeigen oder Tracking-Cookies blockieren – verwenden standardmäßig eine Cookie-Richtlinie, die Cookies von Drittanbietern blockiert. Wenn die Funktion Einbettung ohne Cookies aktiviert ist, können Nutzer in Browsern, die Drittanbieter-Cookies blockieren, Nutzer im eingebetteten iFrame domainübergreifend authentifizieren. Für die Authentifizierung ohne Cookies ist eine serverseitige Konfiguration erforderlich. Beispiele zur Einrichtung finden Sie auf der Dokumentationsseite Einbettung von Cookies ohne Cookies.

Wenn die Funktion Einbettung von Cookies ohne Cookies nicht aktiviert ist, verwendet Looker Cookies für die Nutzerauthentifizierung. In diesem Fall kann in Browsern, die Drittanbieter-Cookies blockieren, nicht versucht werden, den eingebetteten iFrame domainübergreifend zu authentifizieren, es sei denn, der Nutzer ändert die Cookie-Datenschutzeinstellungen seines Browsers. Wenn Sie beispielsweise Informationen in https://mycompany.com einbetten möchten, muss Looker dieselbe Domain verwenden, z. B. https://analytics.mycompany.com. Wenn Ihre Instanz in diesem Fall von Looker gehostet wird, wenden Sie sich an den Looker-Support, um die erforderliche DNS-Konfiguration für die Verwendung der benutzerdefinierten Domain einzurichten. Dadurch kann Looker dieselbe Domain wie die Einbettungsanwendung verwenden und Erstanbieter-Cookies verwenden, 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 verwendet wie Ihre Looker-Instanz.

Clientsichtbarkeit mit einem geschlossenen System steuern

Es ist üblich, dass Looker-Benutzer in einer signierten Einbettungskonfiguration ihren eigenen Kunden Daten präsentieren, während sie Kunden aus verschiedenen Unternehmen oder Gruppen haben, die nichts voneinander wissen sollten. In diesem Szenario sollten Sie privaten Daten geschützt sind, empfehlen wir Ihnen dringend, Looker als geschlossenes System zu konfigurieren, das auch als mehrinstanzenfähige Installation bezeichnet wird. In einem geschlossenen System sind Inhalte isoliert, um zu verhindern, dass Nutzer aus verschiedenen Gruppen sich gegenseitig erfahren. Aus diesem Grund sollten Sie die Option Geschlossenes System aktivieren, bevor Sie externen Nutzern Zugriff auf Ihre Instanz gewähren.

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

Signierte Einbettungs-URL generieren

Es gibt mehrere Möglichkeiten, die signierte Einbettungs-URL zu generieren. Sie können eine der folgenden Methoden verwenden:

Sie können eine signierte Einbettungs-URL generieren. Verwenden Sie dazu die Option Einbettungs-URL abrufen im Dashboard mit drei Punkten eines Dashboards oder über das Zahnradmenü für Explore-Aktionen eines Looks oder Explores.
Verwenden Sie den Endpunkt der signierten Einbettungs-URL in der Looker API erstellen, wie weiter unten in diesem Dokument beschrieben.
Verwenden Sie das Looker Embed SDK.
Codieren Sie die signierte Einbettungs-URL. Damit Sie die URL richtig mit Ihrem geheimen Schlüssel codieren und andere sicherheitsrelevante Elemente generieren können, müssen Sie Code schreiben. Im GitHub-Repository zum Einbetten von Beispielen für Looker finden Sie mehrere Beispielskripts. In den folgenden Abschnitten erfahren Sie, welche Informationen Sie für diese Skripts angeben müssen und wie Sie eine signierte Einbettungs-URL ohne Skript erstellen.

Signierte Einbettungs-URL manuell codieren

Wenn Sie die signierte Einbettungs-URL codieren möchten, erfassen Sie zuerst die erforderlichen Looker-Informationen und erstellen Sie dann die signierte Einbettungs-URL.

Erforderliche Looker-Informationen erfassen

Als Ausgangspunkt für die Erstellung Ihrer URL sollten Sie zunächst alle erforderlichen Informationen ermitteln. Folgendes wird benötigt:

URL einbetten

Rufen Sie die URL des Looks, Explores, der Abfragevisualisierung oder des Dashboards ab, den 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`
Entdecken	`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 `qid=`-Parameter in der Explore-URL folgen, bilden `Query.client_id`. Der Wert `Query.client_id` ist ein eindeutiger String, der die Abfrage- und 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` in Ihre Einbettungs-URL. Sie können die Explore-Benutzeroberfläche von Looker verwenden, um eine Abfrage mit einer unterstützten Visualisierung zu erstellen und den `Query.client_id`-Wert aus dem Parameter `qid=` zu kopieren, oder den `Query.client_id` beispielsweise mit der Looker API mithilfe der Methode `Get Query` abrufen.	`/embed/query-visualization/Query.client_id`
Benutzerdefiniertes Dashboard	`https://instance_name.looker.com/dashboards/1` Fügen Sie alle Dashboard-Filterwerte oder, falls Sie Filterwerte ausblenden, den `hide_filter`-Parameter in die Dashboard-URL ein.
Benutzerdefiniertes älteres Dashboard	`https://instance_name.looker.com/dashboards-legacy/1`	`/embed/dashboards-legacy/1`
LookML-Dashboard	`https://instance_name.looker.com/dashboards/my_model::my_dashboard`	`/embed/dashboards/my_model::my_dashboard`
Legacy-LookML-Dashboard	`https://instance_name.looker.com/dashboards-legacy/my_model::my_dashboard`	`/embed/dashboards-legacy/my_model::my_dashboard`

Eingebetteter Inhalt spiegelt immer die Produktionsversion des Inhalts wider. Änderungen, die im Entwicklermodus vorgenommen werden und sich auf Inhalte auswirken, die noch nicht für die Produktion bereitgestellt wurden, werden nicht in eine Einbettung übernommen.

Berechtigungen

Mit einem Berechtigungssatz wird festgelegt, was ein Nutzer oder eine Gruppe tun kann. Berechtigungen können auf zwei Arten angewendet werden:

Modellspezifisch: Dieser Berechtigungstyp wird nur auf Modellsätze angewendet, die Teil derselben Rolle sind.
Instanzweit:Diese Art von Berechtigung gilt für die Looker-Instanz als Ganzes. Embed-Benutzer mit instanzweiten Berechtigungen können bestimmte Funktionen in der gesamten Looker-Instanz ausführen, können jedoch nicht auf Inhalte basierend auf Modellen zugreifen, die nicht im Modellsatz 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 signierte Einbettungen aufgeführt. Berechtigungen, die nicht in der folgenden Liste aufgeführt sind, werden für signierte Einbettungen 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	Ermöglicht Nutzern die Anzeige von LookML-Dashboards
`see_looks`	`access_data`	Modellspezifisch	Nutzer können Looks ansehen
`see_user_dashboards`	`see_looks`	Modellspezifisch	Nutzer können benutzerdefinierte Dashboards aufrufen und Ordner über eine Einbettung durchsuchen
`explore`	`see_looks`	Modellspezifisch	Nutzer können Erkundungsseiten anzeigen
`create_table_calculations`	`explore`	Instanzweit	Sie mussten Tabellenkalkulationen in einem Explore erstellen.
`create_custom_fields`	`explore`	Instanzweit	<ph type="x-smartling-placeholder"></ph> ADDED 22.4 Erforderlich, um benutzerdefinierte Felder in einem Explore zu erstellen
`can_create_forecast`	`explore`	Instanzweit	<ph type="x-smartling-placeholder"></ph> ADDED 22.12 Damit können Nutzer Prognosen in Visualisierungen erstellen oder bearbeiten.
`save_content`	`see_looks`	Instanzweit	Nutzer können Änderungen an Looks und Dashboards vornehmen und speichern
`send_outgoing_webhook`	`see_looks`	Modellspezifisch	Ermöglicht es dem Benutzer, Looker-Inhaltsübermittlungen an einen beliebigen Webhook zu planen
`send_to_s3`	`see_looks`	Modellspezifisch	Ermöglicht es dem Benutzer, Looker-Inhaltslieferungen an einen Amazon S3-Datenbehälter zu planen
`send_to_sftp`	`see_looks`	Modellspezifisch	Ermöglicht es dem Benutzer, Looker-Inhaltsübermittlungen an einen SFTP-Server zu planen
`schedule_look_emails`	`see_looks`	Modellspezifisch	Damit können Nutzer die Zustellung von Looker-Inhalten an ihre eigene E-Mail-Adresse planen, sofern sie mit einem Nutzerattribut namens „email“ festgelegt ist, oder an eine E-Mail-Adresse, die den Einschränkungen der Zulassungsliste für E-Mail-Domains entspricht. Nutzer mit `create_alerts`-Berechtigungen können Benachrichtigungen an eine E-Mail-Adresse senden, die innerhalb der Einschränkungen der Zulassungsliste für E-Mail-Domains liegt.
`schedule_external_look_emails`	`schedule_look_emails`	Modellspezifisch	Ermöglicht Nutzern die Planung von Looker-Inhaltsübermittlungen an eine beliebige E-Mail-Domain. Nutzer mit `create_alerts`-Berechtigungen können Benachrichtigungen an eine beliebige E-Mail-Domain senden.
`send_to_integration`	`see_looks`	Modellspezifisch	Ermöglicht Nutzern die Bereitstellung von Looker-Inhalten an die in Looker eingebundenen Drittanbieterdienste über den Looker Action Hub. Diese Berechtigung bezieht sich nicht auf Datenaktionen.
`create_alerts`	`see_looks`	Instanzweit	Nutzer können Benachrichtigungen in Dashboard-Tiles erstellen, um Benachrichtigungen zu erhalten, wenn bestimmte Bedingungen erfüllt oder überschritten werden. Nutzer können ihre eigenen Benachrichtigungen und die anderer Nutzer bearbeiten, duplizieren und löschen Öffentliche Warnungen. Wenn der Slack-Workspace des Benutzers nicht mit der Looker-Instanz verbunden ist, kann der Benutzer keine Benachrichtigungen erstellen, die Benachrichtigungen an Slack senden.
`download_with_limit`	`see_looks`	Instanzweit	Ermöglicht dem Nutzer das Herunterladen der Ergebnisse einer Abfrage mit einem angewendeten Limit
`download_without_limit`	`see_looks`	Instanzweit	Ermöglicht dem Nutzer das Herunterladen der Ergebnisse einer Abfrage ohne festgelegte Begrenzung
`see_sql`	`see_looks`	Modellspezifisch	Ermöglicht dem Nutzer die Anzeige des SQL-Codes für Abfragen und aller SQL-Fehler, die aus der Ausführung von Abfragen resultieren
`clear_cache_refresh`	`access_data`	Modellspezifisch	<ph type="x-smartling-placeholder"></ph> ADDED 21.14 Benutzer können den Cache leeren und eingebettete Dashboards, ältere Dashboards, Dashboard-Tiles, Looks und Explores aktualisieren.
`see_drill_overlay`	`access_data`	Modellspezifisch	Lässt Benutzer die Daten aufschlüsseln, ohne die gesamte Explore-Seite aufrufen zu müssen.
`embed_browse_spaces`	Keine	Instanzweit	Aktiviert den Inhaltsbrowser, sodass ein Nutzer Ordner von einer Einbettung aus durchsuchen kann. Jeder Einbettungsnutzer mit der Berechtigung `embed_browse_spaces` erhält Zugriff auf einen persönlichen Einbettungsordner und gegebenenfalls auf den Freigegebenen Ordner Ihrer Organisation. Die Berechtigung `embed_browse_spaces` wird für Nutzer mit der Berechtigung `save_content` empfohlen, damit sie bei der Auswahl des Speicherorts für Inhalte Ordner durchsuchen können. Damit der Nutzer Inhalte in Ordnern sehen kann, benötigt er außerdem die Berechtigungen `see_looks`, `see_user_dashboards` und `see_lookml_dashboards`.
`embed_save_shared_space`	Keine	Instanzweit	<ph type="x-smartling-placeholder"></ph> ADDED 21.4 Nutzer mit der Berechtigung `save_content` können über das Dialogfeld Speichern den Ordner Freigegeben der Organisation aufrufen (falls vorhanden). Nutzer mit der Berechtigung `save_content`, aber nicht mit der Berechtigung `embed_save_shared_space` können Inhalte nur in ihrem persönlichen Einbettungsordner speichern. Die Berechtigung `embed_save_shared_space` überschreibt nicht die Berechtigungen für den Zugriff auf Inhalte. Damit Nutzer beispielsweise im Ordner Freigegeben Inhalte speichern können, benötigen sie weiterhin die Zugriffsrechte Zugriff verwalten, bearbeiten für den Ordner Freigegeben. Außerdem hindert das Fehlen der Berechtigung `embed_save_shared_space` nicht daran, dass ein Nutzer mit der Berechtigung `save_content` und dem Zugriff Zugriff verwalten, bearbeiten auf den Ordner Freigegeben Inhalte dort speichert, wenn er eine alternative Möglichkeit hat, zum Freigegeben-Ordner zu navigieren, z. B. über die Option Von hier aus untersuchen in einem eingebetteten Dashboard.

Modellzugriff

Legen Sie fest, auf welche LookML-Modelle der Benutzer Zugriff haben soll. Dies ist einfach eine Liste mit Modellnamen.

Nutzerattribute

Ermitteln Sie, welche Nutzerattribute der Nutzer gegebenenfalls haben sollte. Sie benötigen den Namen des Benutzerattributs aus Looker sowie den Wert, den der Benutzer für dieses Attribut haben sollte.

Gruppen

Bestimmen Sie, zu welchen Gruppen der Nutzer gehören soll (falls zutreffend). Sie benötigen die Gruppen-IDs und nicht die Gruppennamen. Wenn Sie einen signierten eingebetteten Nutzer zu einer Looker-Gruppe hinzufügen, können Sie den Zugriff dieses Benutzers auf Looker-Ordner verwalten. Nutzer von signierten Einbettungen 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 außerhalb der regulären Looker-Gruppen liegt. In diesem Fall haben signierte Einbettungsnutzer mit derselben external_group_id Zugriff auf einen freigegebenen Ordner namens „Gruppe“. der für die externe Gruppe eindeutig ist.

Eingebettete Rollen

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

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

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

In diesem Fall erhält der eingebettete Nutzer die Berechtigung, die Daten in model_one aufzurufen und zu untersuchen. Die mit den vorherigen Parametern erstellte Rolle „Einbetten“ gewährt ebenfalls die Berechtigung zum Ansehen der Daten in model_two.

Einbettungs-URL erstellen

Eine signierte Einbettungs-URL hat folgendes Format:

https://HOSThttps://EINGEBENE URLhttps://PARAMETERhttps://SIGNATURE

Host

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

URL einbetten

Die Einbettungs-URL wurde bereits ermittelt. Sie hat folgendes Format:

/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 der finalen URL erscheint. das ist richtig.

Wenn Sie eingebettete JavaScript-Ereignisse verwenden, müssen Sie am Ende der Einbettungs-URL ein embed_domain (die Domain, in der der iFrame verwendet wird) hinzufügen:

/embed/looks/4

⇨

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

embed_domain wird nach der Einbettungs-URL und vor allen Parametern hinzugefügt. Wenn Sie also vorhandene Parameter wie nonce=626 hätten, sieht das Hinzufügen von embed_domain so aus:

/embed/looks/4?nonce=626

⇨

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

Wenn du das Embed SDK verwendest, musst du embed_domain und am Ende der Einbettungs-URL sdk=2 hinzufügen:

/embed/looks/4

⇨

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

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

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	Beliebige zufällige Zeichenfolge, die jedoch innerhalb einer Stunde nicht wiederholt werden kann und kürzer als 255 Zeichen sein muss. Dadurch wird verhindert, dass Angreifer die URL eines legitimen Nutzers erneut senden, um unerwünschte Informationen zu erhalten.	JSON-String	`"22b1ee700ef3dc2f500fb7"`
`time`	Wert erforderlich	Die aktuelle Uhrzeit als UNIX-Zeitstempel.	Ganzzahl	`1407876784`
`session_length`	Wert erforderlich	Die Anzahl der Sekunden, die der Benutzer 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 Nutzer signierter Einbettungen zu unterscheiden. Daher muss jedem Nutzer eine eindeutige ID zugewiesen sein. Sie können ein `external_user_id`-Objekt mit einem beliebigen String für einen Nutzer erstellen, solange er für diesen Nutzer eindeutig ist. Jeder ID ist eine Reihe von Berechtigungen, Nutzerattributen und Modellen zugeordnet. Ein einzelner Browser kann jeweils nur eine `external_user_id` oder eine Nutzersitzung unterstützen. Während der Sitzung können keine Änderungen an den Berechtigungen oder Attributen eines Nutzers vorgenommen werden. Achten Sie aus Sicherheitsgründen darauf, dass Sie nicht dasselbe `external_user_id` in verschiedenen Einbettungssitzungen für verschiedene interaktive Nutzer verwenden, und achten Sie darauf, nicht dasselbe `external_user_id` für einen einzelnen Nutzer mit unterschiedlichen Berechtigungen, Nutzerattributwerten oder Modellzugriffen zu verwenden. Wenn Sie dieselbe `external_user_id` für mehrere Nutzer oder denselben Nutzer mit mehreren Berechtigungen, Nutzerattributen oder Modellsätzen verwenden, können Daten für Nutzer sichtbar sein, die andernfalls keinen Zugriff darauf hätten.	JSON-String	`"user-4"`
`permissions`	Wert erforderlich	Die Liste der Berechtigungen, die der Nutzer haben sollte. Im Abschnitt Berechtigungen dieser Seite finden Sie eine Liste der zulässigen Berechtigungen.	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 sollte, sofern vorhanden. Verwenden Sie anstelle von Gruppennamen Gruppen-IDs.	Stringarray	`["4", "3"]`
`external_group_id`	""	Eine eindeutige Kennung für die Gruppe, der der Benutzer in der Anwendung angehört, die Looker einbettet, falls gewünscht. Nutzer mit der Berechtigung zum Speichern von Inhalten und Freigeben einer externen Gruppen-ID können Inhalte in einem freigegebenen Looker-Ordner namens „Gruppe“ 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 Einbettungsbenutzergruppen über die Looker-Benutzeroberfläche zu konfigurieren.	JSON-String	`"Accounting"`
`user_attributes`	{}	Die Liste der Nutzerattribute, die der Nutzer haben sollte, falls vorhanden. Enthält eine Liste mit Namen von Nutzerattributen, gefolgt vom Wert des Nutzerattributs. Wenn dein LookML-Modell lokalisiert ist, kannst du mit dem Nutzerattribut `locale` in der Einbettungs-URL eine Sprache für die Einbettung angeben. Der Parameter `user_attributes { "locale" : "fr_FR" }` würde beispielsweise bewirken, dass die Einbettung Französisch als Sprache lädt.	Hash-Wert 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. Verwende `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 ist „Einbetten“. falls 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 aus der letzten Anfrage bei oder ist „Einbetten“. wenn noch kein Nachname festgelegt wurde.	JSON-String	`"Jones"`
`user_timezone`	""	Wenn Sie Nutzerspezifische Zeitzonen aktiviert haben, legen Sie den Wert der Option Zeitzone des Betrachters im Drop-down-Menü Zeitzone des eingebetteten Looks oder Dashboards fest. Durch diesen Parameter wird die Zeitzone, in der die Inhalte angezeigt werden, nicht direkt geändert. muss der Nutzer eine Zeitzone aus dem Drop-down-Menü auswählen. Gültige Werte finden Sie auf der Dokumentationsseite Zeitzone für signierte Einbettungen. Tipp für das Chat-Team:Wenn für deine eingebetteten Inhalte standardmäßig die Zeitzone des Zuschauers verwendet werden soll, hast du folgende Möglichkeiten: Füge der URL für die Einbettung den Parameter `?query_timezone=user_timezone` hinzu. Beispiel: `/embed/dashboards/1?query_timezone=user_timezone` Speichern Sie das eingebettete Dashboard oder den Look, wobei die Standardzeitzone auf Zeitzone des Betrachters eingestellt ist. Dadurch wird standardmäßig die Zeitzone des Nutzers sowohl für eingebettete Nutzer als auch für Nutzer ohne eingebettete Inhalte 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 anzeigt, können Sie Folgendes festlegen: 1) sollte sich das Element mit seinen aktuellen Anmeldedaten ansehen. oder 2) sollte er abgemeldet und mit den signierten Anmeldedaten für die Einbettung wieder angemeldet werden.	Boolesch (wahr oder falsch)	`true`

Unterschrift

Looker verwendet die Signatur, um zu prüfen, ob zum Generieren der Signatur in der Einbettungs-URL das richtige Einbettungsgeheimnis verwendet wurde und ob sich die Parameter in der Einbettungs-URL nicht 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 bietet daher einen kryptografisch starken Nachweis, dass die Einbettungs-URL bei der Übertragung nicht geändert wurde und von einer vertrauenswürdigen Partei erstellt wurde, die im Besitz des geheimen Schlüssels für die Einbettung ist.

Gehen Sie folgendermaßen vor, um die Signatur zu erstellen:

Erfassen Sie die folgenden Parameterwerte in dieser Reihenfolge: <ph type="x-smartling-placeholder">
- 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 (leerer Platzhalter erforderlich)
Alle Werte außer Host und Einbettungs-URL als JSON formatieren
Werte mit Zeilenumbrüchen verketten (\n)
HMAC-SHA1-Signatur des verketteten Strings mit Ihrem geheimen Looker-Einbettungsschlüssel

Codierung

Der letzte Schritt besteht darin, die URL zu codieren.

Bevor Sie die URL codieren, sieht eine korrekt formatierte Einbettungs-URL unter Verwendung aller möglichen Parameter in etwa so aus:

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={}&
first_name="Alice"&
last_name="Jones"&
user_timezone="US/Pacific"&
force_logout_login=true&
signature=123456789ABCDEFGHIJKL

Wie bereits erwähnt, erscheint /embed//embed/ korrekt in Ihrer URL.

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
first_name=%22Alice%22&
last_name=%22Jones%22&
user_timezone=%22US%2FPacific%22&
force_logout_login=true&
signature=123456789ABCDEFGHIJKL

API-Endpunkt zum Erstellen einer signierten Einbettungs-URL verwenden

Die Looker API enthält den Endpunkt Signierte Einbettungs-URL erstellen. Dieser enthält eine Reihe signierter Einbettungsparameter, einschließlich der URL des einzubettenden Inhalts, und gibt eine vollständige, codierte, kryptografisch signierte URL zurück.

Damit dieser API-Endpunkt über einen Webserver verwendet werden kann, muss sich der Webserver mit Administratorberechtigungen bei der Looker API authentifizieren können. Die Webserverdomain muss auch in der Zulassungsliste für eingebettete Domains aufgeführt sein.

Sie können auch mit dem API Explorer eine signierte URL generieren, die diesen Endpunkt verwendet. Sie können den API Explorer über den Looker Marketplace auf Ihrer Looker-Instanz installieren. Nach der Generierung muss die signierte URL genau kopiert werden und kann nur einmal verwendet werden. Andernfalls schlägt sie fehl. Der API Explorer ist auch nützlich, um eine signierte URL zu generieren und zur Fehlerbehebung 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

Zum Testen der finalen URL fügen Sie sie im Looker-Bereich Admin auf der Seite Einbetten in das Tool Embed URI Validator (URI-Validierung einbetten) ein. Mit dieser Option können Sie zwar nicht feststellen, ob die gewünschten Daten und Berechtigungen richtig eingerichtet wurden, aber Sie können damit prüfen, ob die Authentifizierung ordnungsgemäß funktioniert.