Signierte Einbettung

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

Signierte Einbettungen sind eine Möglichkeit, Ihren Benutzern private eingebettete Looks, Visualisierungen, Explores, Dashboards oder LookML-Dashboards zu präsentieren, ohne dass diese einen separaten Looker-Log-in benötigen. Stattdessen werden Nutzer über Ihre eigene Anwendung authentifiziert.

Beim signierten Einbetten 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. Dann signieren Sie die URL mit einem geheimen Schlüssel von Looker.

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

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

Richtiges Hosting für signierte Einbettungen

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

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

Wenn die Funktion Einbetten ohne Cookies nicht aktiviert ist, verwendet Looker Cookies für die Nutzerauthentifizierung. In diesem Fall ist die domainübergreifende Authentifizierung des eingebetteten iFrames in Browsern, die Drittanbieter-Cookies blockieren, nicht möglich, es sei denn, der Nutzer ändert die Cookie-Datenschutzeinstellungen seines Browsers. Wenn Sie beispielsweise Informationen in 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, müssen Sie in diesem Fall den Looker-Support kontaktieren, um die DNS-Konfiguration einzurichten, die zur Aktivierung der Verwendung benutzerdefinierter Domains erforderlich ist. 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 signierte Einbettungen verwendet, dieselbe Domain wie Ihre Looker-Instanz verwendet.

Sichtbarkeit von Clients mit einem geschlossenen System steuern

In einer signierten Einbettungskonfiguration präsentieren Looker-Benutzer ihren eigenen Kunden Daten, während Kunden aus verschiedenen Unternehmen oder Gruppen haben, die nichts voneinander wissen sollten. In diesem Szenario empfehlen wir zum Schutz der privaten Informationen Ihrer Kunden dringend, Looker als geschlossenes System, auch als mehrinstanzenfähige Installation bezeichnet, zu konfigurieren. In einem geschlossenen System werden Inhalte isoliert, um zu verhindern, dass Nutzer verschiedener Gruppen voneinander wissen. Aus diesem Grund 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 Ein System mit Zugriffsebenen entwerfen und konfigurieren und in den Dokumentationsseiten 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, indem Sie die Option Einbettungs-URL abrufen im Dashboard-Menü mit den drei Punkten eines Dashboards oder im Zahnradmenü für Explore-Aktionen eines Looks oder Explores verwenden.

• Verwenden Sie den Looker API-Endpunkt zum Erstellen signierter Einbettungs-URLs, wie weiter unten in diesem Dokument beschrieben.

• Verwenden Sie das Looker Embed SDK.

• Codiere die signierte Einbettungs-URL. Zum Erstellen der richtigen URL müssen Sie Code schreiben, damit Sie die URL ordnungsgemäß mit Ihrem geheimen Schlüssel codieren und weitere sicherheitsrelevante Elemente generieren können. Im GitHub-Repository zum Einbetten von Beispielen finden Sie mehrere Beispielskripts von Looker. In den folgenden Abschnitten wird erläutert, welche Informationen in diesen Skripts angegeben werden müssen und wie du eine signierte Einbettungs-URL ohne Script erstellen kannst.

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

Bei der Erstellung Ihrer URL sollten Sie zunächst alle Informationen ermitteln, die enthalten sein müssen. Folgendes wird benötigt:

URL einbetten

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

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 Query.client_id sind die 22 alphanumerischen Zeichen, die in der Explore-URL auf den Parameter qid= folgen. Der Wert Query.client_id ist ein eindeutiger String, der die Abfrage- und Visualisierungseinstellungen darstellt. Um eine Abfragevisualisierung einzubetten, rufen Sie den Query.client_id-Wert der Abfragevisualisierung ab und kopieren Sie Query.client_id in Ihre Einbettungs-URL. Sie können die Explore-UI von Looker verwenden, um eine Abfrage mit einer unterstützten Visualisierung zu erstellen und den Query.client_id-Wert aus dem qid=-Parameter zu kopieren. Sie können auch die Query.client_id mit der Looker API abrufen, beispielsweise mithilfe der Methode Get Query.	/embed/query-visualization/Query.client_id
Benutzerdefiniertes Dashboard	https://instance_name.looker.com/dashboards/1 Fügen Sie alle Dashboardfilterwerte in die Dashboard-URL ein. Wenn Sie Filterwerte ausblenden, müssen Sie außerdem den Parameter hide_filter in die Dashboard-URL einfügen.
Benutzerdefiniertes Legacy-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. Alle Änderungen, die im Entwicklungsmodus vorgenommen werden und sich auf Inhalte auswirken und nicht für die Produktion bereitgestellt wurden, werden in einer Einbettung nicht angezeigt.

Berechtigungen

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

• Modellspezifisch: Diese Art von Berechtigung wird nur auf Modellsätze angewendet, die zur selben Rolle gehören.
• Instanzweit:Diese Art von Berechtigung gilt für die Looker-Instanz als Ganzes. Einbettungsnutzer mit instanzweiten Berechtigungen können bestimmte Funktionen in der gesamten Looker-Instanz ausführen, jedoch nicht auf Inhalte zugreifen, die auf Modellen basieren, die nicht im Modellsatz ihrer Rolle enthalten sind.

Bestimmen Sie die Berechtigungen, die der Nutzer haben soll. Die folgende Liste zeigt alle verfügbaren Berechtigungen für signierte Einbettungen. Berechtigungen, die nicht auf der folgenden Liste stehen, werden für das signierte Einbetten nicht unterstützt:

Berechtigung	Abhängig von	Typ	Definition
access_data	Keine	Modellspezifisch	Ermöglicht Benutzern den Zugriff auf Daten (erforderlich zum Anzeigen von Looks, Dashboards oder Explores)
see_lookml_dashboards	access_data	Modellspezifisch	Ermöglicht es Nutzern, LookML-Dashboards anzusehen
see_looks	access_data	Modellspezifisch	Nutzer können Looks sehen
see_user_dashboards	see_looks	Modellspezifisch	Nutzer können benutzerdefinierte Dashboards sehen und Ordner aus einer Einbettung durchsuchen
explore	see_looks	Modellspezifisch	Nutzer können Erkundungsseiten aufrufen
create_table_calculations	explore	Instanzweit	Muss Tabellenkalkulationen in einem Explore erstellen
create_custom_fields	explore	Instanzweit	ADDED 22.4 Zum Erstellen von benutzerdefinierten Feldern in einem Explore erforderlich
can_create_forecast	explore	Instanzweit	ADDED 22.12 Ermöglicht Nutzern, Prognosen in Visualisierungen zu erstellen oder zu bearbeiten.
save_content	see_looks	Instanzweit	Ermöglicht es dem Nutzer, Änderungen an Looks und Dashboards vorzunehmen und zu speichern
send_outgoing_webhook	see_looks	Modellspezifisch	Ermöglicht es dem Nutzer, Looker-Inhaltsübermittlungen an einen beliebigen Webhook zu planen
send_to_s3	see_looks	Modellspezifisch	Ermöglicht es dem Nutzer, Looker-Inhaltsübermittlungen an einen Amazon S3-Datenbehälter zu planen
send_to_sftp	see_looks	Modellspezifisch	Ermöglicht es dem Nutzer, die Übermittlung von Looker-Inhalten an einen SFTP-Server zu planen
schedule_look_emails	see_looks	Modellspezifisch	Damit können Nutzer die Übermittlung von Looker-Inhalten für Looker-Inhalte an ihre eigene E-Mail-Adresse (wenn diese mit dem Nutzerattribut „email“ festgelegt ist) oder an eine E-Mail-Adresse planen, die den Einschränkungen in der Zulassungsliste für E-Mail-Domains entspricht. Nutzer mit der Berechtigung create_alerts dürfen Benachrichtigungen an eine E-Mail-Adresse senden, die den Einschränkungen in der Zulassungsliste für E-Mail-Domains entspricht.
schedule_external_look_emails	schedule_look_emails	Modellspezifisch	Damit können Nutzer die Übermittlung von Looker-Inhalten an eine beliebige E-Mail-Domain planen. Ermöglicht einem Nutzer mit der Berechtigung create_alerts das Senden von Warnmeldungen an eine beliebige E-Mail-Domain.
send_to_integration	see_looks	Modellspezifisch	Ermöglicht es Nutzern, über den Looker Action Hub Looker-Inhalte an in Looker integrierte Drittanbieterdienste zu liefern. Diese Berechtigung bezieht sich nicht auf Datenaktionen.
create_alerts	see_looks	Instanzweit	Der Nutzer kann Warnungen zu Dashboardkacheln erstellen, um informiert 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 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	Nutzer können die Ergebnisse einer Abfrage ohne Begrenzung herunterladen
see_sql	see_looks	Modellspezifisch	Ermöglicht es dem Nutzer, die SQL für Abfragen und alle SQL-Fehler zu sehen, die sich aus laufenden Abfragen ergeben
clear_cache_refresh	access_data	Modellspezifisch	ADDED 21.14 Nutzer können eingebettete Dashboards, ältere Dashboards, Dashboardkacheln, Looks und Explores im Cache leeren und aktualisieren.
see_drill_overlay	access_data	Modellspezifisch	Damit können Nutzer Drilldown-Vorgänge ausführen, ohne die vollständige Seite „Explore“ aufrufen zu müssen.
embed_browse_spaces	Keine	Instanzweit	Aktiviert den Inhaltsbrowser, sodass Nutzer Ordner aus einer eingebetteten Datei durchsuchen können. Jeder Einbettungsnutzer mit der Berechtigung embed_browse_spaces erhält Zugriff auf einen persönlichen Einbettungsordner und auf den freigegebenen Ordner deiner Organisation, falls vorhanden. Die Berechtigung embed_browse_spaces wird für Nutzer mit der Berechtigung save_content empfohlen, damit Nutzer bei der Auswahl des Speicherorts für Inhalte Ordner durchsuchen können. Um Inhalte in Ordnern zu sehen, benötigt der Nutzer außerdem die Berechtigungen see_looks, see_user_dashboards und see_lookml_dashboards.
embed_save_shared_space	Keine	Instanzweit	ADDED 21.4 Ermöglicht es Nutzern, die auch die Berechtigung save_content haben, über das Dialogfeld Speichern zum Ordner Freigegeben der Organisation zu wechseln, falls vorhanden. Nutzer mit der Berechtigung save_content, aber nicht der Berechtigung embed_save_shared_space haben nur die Möglichkeit, Inhalte in ihrem persönlichen Einbettungsordner zu speichern. Die Berechtigung embed_save_shared_space überschreibt keine Zugriffsberechtigungen für Inhalte. Damit Nutzer beispielsweise Dateien im Ordner Freigegeben speichern können, benötigen sie für den Ordner Freigegeben noch die Zugriffsberechtigung Zugriff verwalten, Bearbeiten. Darüber hinaus hindert das Fehlen der Berechtigung embed_save_shared_space einen Nutzer mit der Berechtigung save_content und der Zugriffsberechtigung Zugriff verwalten, Bearbeiten für den Ordner Freigegeben nicht daran, Inhalte dort zu speichern, falls er eine andere Möglichkeit hat, zum Ordner Freigegeben zu wechseln, z. B. über die Option Von hier aus ansehen in einem eingebetteten Dashboard.

Modellzugriff

Legen Sie fest, auf welche LookML-Modelle der Nutzer 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

Legen Sie fest, welchen Gruppen der Nutzer angehören soll, sofern zutreffend. Sie benötigen die Gruppen-IDs, nicht die Gruppennamen. Wenn Sie einer Looker-Gruppe einen signierten Einbettungsnutzer hinzufügen, können Sie dessen Zugriff auf Looker-Ordner verwalten. Nutzer mit signierten Einbettungen haben Zugriff auf alle Ordner, die für Mitglieder ihrer Looker-Gruppen freigegeben wurden.

Sie können auch den Parameter external_group_id verwenden, um eine Gruppe außerhalb der regulären Looker-Gruppen zu erstellen. In diesem Fall haben signierte Einbettungsnutzer mit derselben external_group_id Zugriff auf einen freigegebenen Ordner namens „Gruppe“, der für diese externe Gruppe eindeutig ist.

Hinweis: Der Parameter external_group_id ist die einzige verfügbare Methode zum Erstellen externer Gruppen eingebetteter Nutzer. Es ist nicht möglich, externe Nutzergruppen eingebetteter Inhalte über die Looker-UI zu konfigurieren.

Eingebettete Rollen

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

Angenommen, Sie haben in Looker bereits eine Gruppe mit der Gruppen-ID 1 und diese Gruppe hat bereits die Berechtigung explore für ein Modell namens model_one und 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 zum Ansehen und Erkunden der Daten in model_one. Die mit den vorherigen Parametern erstellte Einbettungsrolle gewährt auch die Möglichkeit, die Daten auf model_two anzusehen.

Einbettungs-URL erstellen

Eine signierte Einbettungs-URL hat das folgende Format:

https://HOSThttps://EINBETTEN URLhttps://PARAMETERhttps://SIGNATURE

Host

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

URL einbetten

Die Einbettungs-URL wurde bereits festgelegt. Sie hat ein Format wie:

• /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 angezeigt wird. Das ist richtig.

Wenn Sie eingebettete JavaScript-Ereignisse verwenden, müssen Sie am Ende der Einbettungs-URL eine embed_domain (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 eingefügt. Wenn Sie also Parameter wie nonce=626 haben, würde das Hinzufügen von embed_domain so aussehen:

/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 sdk=2 am Ende der Einbettungs-URL hinzufügen. Das sieht dann so aus:

/embed/looks/4

⇨

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

Anhand des sdk=2-Parameters 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.

Parameter

Mit den folgenden URL-Parametern werden die erforderlichen Informationen für die signierte Einbettung angegeben:

Parameter	Standardwert	Beschreibung	Datentyp	Beispiel
nonce	Wert erforderlich	Eine beliebige Zeichenfolge, die nicht innerhalb einer Stunde wiederholt werden kann und darf nicht länger als 255 Zeichen sein. So wird verhindert, dass ein Angreifer die URL eines legitimen Nutzers noch einmal einreicht, um Informationen zu erhalten, die er nicht haben sollte.	JSON-String	"22b1ee700ef3dc2f500fb7"
time	Wert erforderlich	Die aktuelle Zeit als UNIX-Zeitstempel.	Integer	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).	Integer	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 werden. Sie können ein external_user_id-Objekt für einen Nutzer mit einem beliebigen String erstellen, der für diesen Nutzer eindeutig ist. Jeder ID ist eine Reihe von Berechtigungen, Nutzerattributen und Modellen zugeordnet. Ein einzelner Browser kann immer nur eine external_user_id (Nutzersitzung) unterstützen. Während einer Sitzung können die Berechtigungen oder Attribute eines Nutzers nicht geändert werden. Aus Sicherheitsgründen sollten Sie darauf achten, dass Sie nicht dieselbe external_user_id für verschiedene Einbettungssitzungen für unterschiedliche interaktive Nutzer verwenden. Verwenden Sie auch nicht dieselbe external_user_id für einen einzelnen Nutzer, der unterschiedliche Berechtigungen, Nutzerattributwerte oder Modellzugriff hat. Wenn dieselbe external_user_id für mehrere Nutzer oder für denselben Nutzer mit mehreren Berechtigungen, Nutzerattributen oder Modellsätzen verwendet wird, sind Daten möglicherweise auch für Nutzer sichtbar, 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 auf dieser Seite im Abschnitt 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, 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, falls gewünscht. Nutzer, die die Berechtigung zum Speichern von Inhalten und zum Teilen einer externen Gruppen-ID haben, können Inhalte in einem freigegebenen Looker-Ordner namens „Gruppe“ speichern und bearbeiten. Der Parameter external_group_id ist die einzige Methode zum Erstellen externer Gruppen eingebetteter Nutzer. Es gibt keine Möglichkeit, externe eingebettete Nutzergruppen ü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 Ihr LookML-Modell lokalisiert ist, können Sie mithilfe des Nutzerattributs locale in der Einbettungs-URL eine Sprache für die Einbettung angeben. Wenn du beispielsweise den Parameter user_attributes { "locale" : "fr_FR" } angibst, würde die Einbettung dazu führen, dass Französisch als Sprache geladen wird.	Hash von Strings	{   "vendor_id" : "17",   "company" : "xactness" }
access_filters	Wert erforderlich	In Looker 3.10 wurde dieser Parameter entfernt, er ist aber in der URL weiterhin erforderlich. Verwenden Sie access_filters mit einem leeren Platzhalter, z. B. access_filters={}.	Leerer Platzhalter	{}
first_name	""	Der Vorname des Nutzers. Wenn das Feld leer bleibt, behält first_name den Wert aus der letzten Anfrage bei oder „Embed“ (Einbetten), wenn bisher noch kein Vorname festgelegt wurde.	JSON-String	"Alice"
last_name	""	Der Nachname des Nutzers. Wenn das Feld leer gelassen wird, behält last_name den Wert aus der letzten Anfrage bei oder „Embed“ (Einbetten), wenn bisher noch kein Nachname festgelegt wurde.	JSON-String	"Jones"
user_timezone	""	Wenn Sie Nutzerspezifische Zeitzonen aktiviert haben, legen Sie den Wert für die Option Zeitzone des Betrachters im Drop-down-Menü Zeitzone des eingebetteten Looks oder Dashboards fest. Durch diesen Parameter wird die Zeitzone, in der der Content angezeigt wird, nicht direkt geändert. Der Nutzer muss eine Zeitzone aus dem Drop-down-Menü auswählen. Gültige Werte finden Sie auf der Dokumentationsseite Zeitzonenreferenz für signierte Einbettungen. Tipp für das Chat-Team:Wenn du möchtest, dass für deine eingebetteten Inhalte standardmäßig die Zeitzone des Zuschauers verwendet wird, hast du folgende Möglichkeiten: Füge der Einbettungs-URL den Parameter ?query_timezone=user_timezone hinzu. Beispiel: /embed/dashboards/1?query_timezone=user_timezone Speichern Sie das eingebettete Dashboard oder den Look und legen Sie die Standardzeitzone auf Zeitzone des Betrachters fest. 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-Nutzer bereits bei Looker angemeldet ist und ein signiertes eingebettetes Element sieht, können Sie zwischen folgenden Optionen wählen: 1) Er sollte das Element mit seinen aktuellen Anmeldedaten aufrufen. oder 2) Sie sollten abgemeldet und mit den signierten Anmeldedaten zum Einbetten wieder angemeldet werden.	Boolesch (wahr oder falsch)	true

Unterschrift

So generieren Sie eine 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 (leerer Platzhalter erforderlich)
2. Alle Werte außer „Host“ und „URL einbetten“ als JSON formatieren
3. Die Werte mit Zeilenumbrüchen verketten (\n)
4. HMAC signiert den verketteten String mit Ihrem geheimen Looker-Einbettungsschlüssel

Codierung

Im letzten Schritt muss die URL per URL-Codierung codiert werden.

Vor dem Codieren der URL könnte eine korrekt formatierte Einbettungs-URL mit allen möglichen Parametern in etwa 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={}&
first_name="Alice"&
last_name="Jones"&
user_timezone="US/Pacific"&
force_logout_login=true&
signature=123456789ABCDEFGHIJKL

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

Nach dem Codieren der URL sieht sie 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 „Signierte Embed Url erstellen“ verwenden

Die Looker API umfasst den Endpunkt Create Signed Embed Url (Signierte Einbettungs-URL erstellen). Dieser verwendet eine Reihe signierter Einbettungsparameter, die die URL des Inhalts enthalten, den Sie einbetten möchten, und gibt eine vollständige, codierte, kryptografisch signierte URL zurück.

Damit dieser API-Endpunkt auf einem 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 den API 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. Nach der Erstellung muss die signierte URL genau kopiert werden und kann nur einmal verwendet werden. Andernfalls schlägt die URL 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

Um die finale URL zu testen, fügen Sie sie in Looker im Bereich Verwaltung auf der Seite Einbetten in das Feld URI-Validierung einbetten ein. Mit dieser Option können Sie zwar nicht feststellen, ob die von Ihnen vorgesehenen Daten und Berechtigungen korrekt eingerichtet wurden, aber sie prüft, ob Ihre Authentifizierung ordnungsgemäß funktioniert.