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 signierte Einbettungen in Ihrer Looker-Instanz verwenden können, muss ein Looker-Administrator signierte Einbettungen im Admin-Bereich von Looker aktivieren und einen Einbettungs-Secret-Key erstellen. Eine Anleitung finden Sie auf der Dokumentationsseite Erste Schritte mit dem Einbetten – Signiertes Einbetten 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.
Wenn die Funktion Einbetten ohne Cookies 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 benutzerdefinierter Domains 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 Fall empfehlen wir dringend, Looker als geschlossenes System zu konfigurieren, um die privaten Informationen Ihrer Kunden zu schützen. Dies wird auch als Multi-Tenant-Installation bezeichnet. In einem geschlossenen System werden Inhalte in Silos zusammengefasst, um zu verhindern, dass sich Nutzer aus verschiedenen Gruppen untereinander kennen. 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 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. Mehrere Beispielskripts finden Sie im GitHub-Repository für Looker-Einbettungsbeispiele. 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.
Signierte Einbettungs-URL manuell codieren
Wenn Sie die signierte Einbettungs-URL codieren möchten, 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 Visualisierung der Abfrage 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=1234567890abcdefghij12Die 22 alphanumerischen Zeichen, die dem 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 Wert Query.client_id der Abfragevisualisierung ab und kopieren Sie den Query.client_id 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 Query.client_id-Wert aus dem qid=-Parameter zu kopieren. Alternativ können Sie den Query.client_id-Wert 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/1Fügen Sie alle Dashboardfilterwerte, mit denen Filterwerte ausgeblendet werden, in den Parameter hide_filter in der Dashboard-URL ein. |
/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 Seite „Unterhaltungen“: https://instance_name.looker.com/conversationsFür die Seite „KI-Agenten“: https://instance_name.looker.com/agentsFür eine bestimmte Unterhaltung: https://instance_name.looker.com/conversations/conversation_idWeitere Informationen finden Sie auf der Dokumentationsseite Dialogorientierte Analysen einbetten. |
/embed/conversations/embed/agents/embed/conversations/c9f370ac830b4669aeb494396422004c |
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 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 das signierte Einbetten aufgeführt. Berechtigungen, die nicht in der folgenden Liste aufgeführt sind, werden für das signierte Einbetten nicht unterstützt:
| Berechtigung | Abhängig von | Typ | Definition |
|---|---|---|---|
access_data |
Keine | Modellspezifisch | Ermöglicht dem Nutzer den Zugriff auf Daten (erforderlich zum Aufrufen 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 | Nutzern erlauben, Looks zu sehen |
see_user_dashboards |
see_looks |
Modellspezifisch | Ermöglicht es Nutzern, benutzerdefinierte Dashboards anzusehen 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 es 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 | Nutzern ermöglichen, die Lieferung von Looker-Inhalten an einen Amazon S3-Bucket zu planen |
send_to_sftp |
see_looks |
Modellspezifisch | Ermöglicht es Nutzern, die Bereitstellung von Looker-Inhalten an einen SFTP-Server zu planen |
schedule_look_emails |
see_looks |
Modellspezifisch | Ermöglicht es Nutzern, die Zustellung von Looker-Inhalten an ihre eigene E-Mail-Adresse (sofern mit einem Nutzerattribut namens „email“ festgelegt) oder an eine E-Mail-Adresse zu planen, die den durch die Zulassungsliste mit E-Mail-Domains festgelegten Einschränkungen 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 es Nutzern, 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 | Hinzugefügt: 26.4 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, bei denen alle Datenzeilen gesendet werden. Mit dieser Berechtigung wird die Option Alle Ergebnisse im Looker-Planer für Looks und Explores sichtbar. |
create_alerts |
see_looks |
Instanzweit | Ermöglicht es Nutzern, Benachrichtigungen für Dashboard-Kacheln zu erstellen, um Benachrichtigungen zu erhalten, 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 es Nutzern, die Ergebnisse einer Abfrage mit einem angewendeten Limit herunterzuladen |
download_without_limit |
see_looks |
Instanzweit | Ermöglicht es dem Nutzer, die Ergebnisse einer Abfrage ohne Limit 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 | Nutzer können Daten untersuchen, ohne die vollständige Seite „Explore“ 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 geteilten Ordner Ihrer Organisation, falls vorhanden.
Die Berechtigung embed_browse_spaces wird für Nutzer mit der Berechtigung save_content empfohlen, damit sie beim Auswählen des Speicherorts für Inhalte in Ordnern suchen können.
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 navigieren, sofern ein solcher Ordner vorhanden ist. 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. Wenn ein Nutzer nicht die Berechtigung embed_save_shared_space hat, kann er trotzdem Inhalte im Ordner Freigegeben speichern, sofern er die Berechtigung save_content und Zugriff verwalten, bearbeiten für den Ordner Freigegeben hat und auf andere Weise darauf zugreifen kann, 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 Bereich Admin 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 KI-Dashboard-Agenten. Für den Chat mit Dashboard-Daten-Agents sind zusätzliche Berechtigungen erforderlich. |
chat_with_explore |
chat_with_agent |
Modellspezifisch | Hinzugefügt: 25.18 Nutzer der konversationellen Analyse können mit einem Looker-Explore chatten, wenn sie auch über zusätzliche erforderliche Berechtigungen verfügen. |
save_agents |
chat_with_explore |
Modellspezifisch | Hinzugefügt am 25.18 Nutzer von konversationeller Analyse können Daten-Agents auf Dashboards oder Explores erstellen, bearbeiten, löschen und freigeben. Wenn Nutzer einen von einem anderen Nutzer erstellten KI-Datenagenten bearbeiten, löschen oder freigeben möchten, muss ihnen eine Rolle zugewiesen werden, die diese Berechtigung für jedes vom KI-Agenten verwendete Modell enthält. Außerdem benötigen sie zusätzliche erforderliche Berechtigungen und Zugriff verwalten, Bearbeitungszugriff für den KI-Agenten. |
admin_agents |
gemini_in_looker |
Modellspezifisch | Hinzugefügt am 25.18 Nutzer können KI-Datenagenten für die Verwendung mit der Conversational Analytics API und eingebetteten konversationellen Analysen 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 die Inhalte des Daten-KI-Agenten gewährt werden, um einen von einem anderen Nutzer erstellten Daten-KI-Agenten zu bearbeiten, zu löschen oder zu teilen. |
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 außerhalb der regulären Looker-Gruppen liegt. In diesem Fall haben Nutzer mit signierten Einbettungen und demselben external_group_id Zugriff auf einen freigegebenen Ordner namens „Gruppe“, der nur für die externe Gruppe gilt.
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 Looker-Bereich Admin 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 in der Gruppenauswahlliste 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. 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 erbt der eingebettete Nutzer die Möglichkeit, die Daten in model_one anzusehen und zu untersuchen. Die mit den vorherigen Parametern erstellte eingebettete Rolle gewährt auch die Möglichkeit, die Daten in 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/1oder/embed/dashboards-legacy/1/embed/dashboards/my_model::my_dashboardoder/embed/dashboards-legacy/my_model::my_dashboard
Das bedeutet, dass das Muster /embed//embed/ in Ihrer finalen URL angezeigt wird. Das ist korrekt.
Wenn Sie eingebettete JavaScript-Ereignisse verwenden, müssen Sie den Parameter embed_domain (die Domain, in 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 enthält (z. B. Filterwerte), 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 genutzt werden können. 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 | Ein beliebiger zufälliger 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 Zeit als UNIX-Zeitstempel. | Ganzzahl | 1407876784 |
session_length |
Wert erforderlich | Die Anzahl der Sekunden zwischen 0 und 2.592.000 (30 Tage), die der Nutzer bei Looker angemeldet bleiben soll. | Ganzzahl | 86400 |
external_user_id |
Wert erforderlich | Eine Kennung für jeden Nutzer in der Anwendung, in die Looker eingebettet ist. In Looker wird external_user_id verwendet, um zwischen angemeldeten eingebetteten Nutzern zu unterscheiden. Jeder Nutzer muss daher eine eindeutige ID haben.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 nicht während einer Sitzung geändert werden.Aus Sicherheitsgründen sollten Sie nicht dieselbe external_user_id für verschiedene Einbettungssitzungen für verschiedene interaktive Nutzer verwenden. Außerdem sollten Sie nicht dieselbe external_user_id für einen einzelnen Nutzer verwenden, der unterschiedliche Berechtigungen, Attributwerte 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. | String-Array | [ "access_data", "see_looks"] |
models |
Wert erforderlich | Die Liste der Modellnamen, auf die der Nutzer Zugriff haben soll. | String-Array | [ "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. | String-Array | ["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 gemeinsam nutzen, können Inhalte in einem gemeinsamen Looker-Ordner mit dem Namen „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 die 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 Nutzerattribut 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 das eingebettete Element auf Französisch 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 aus 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 des eingebetteten Looks oder Dashboards 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 Ihre eingebetteten Inhalte standardmäßig in der Zeitzone des Betrachters angezeigt werden, verwenden Sie eine der folgenden Methoden:?query_timezone=user_timezone der Einbettungs-URL hinzu. Beispiel:/embed/dashboards/1?query_timezone=user_timezone |
JSON-String oder null | "US/Pacific"– oder –null |
force_logout_login |
Wert erforderlich | Wenn ein normaler Looker-Nutzer bereits in Looker angemeldet ist und ein signiertes eingebettetes Element aufruft, können Sie Folgendes festlegen:1) Sie sollten das Element mit ihren aktuellen Anmeldedaten aufrufen.oder2) Sie sollten sich ab- und dann 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 |
Boolescher Wert (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 bietet daher einen kryptografisch starken 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 den Einbettungs-Secret-Schlüssel besitzt.
So generieren Sie die Signatur:
- 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-Agenten im Dashboard für konversationelle Analysen
- Host, gefolgt von
- Alle Werte außer Host und Einbettungs-URL als JSON formatieren
- Verketten Sie die Werte mit Zeilenumbrüchen (
\n). - Signieren Sie den verketteten String mit Ihrem Looker-Einbettungs-Secret-Key mit HMAC-SHA1.
Codierung
Im letzten Schritt müssen Sie Ihre URL URL-codieren.
Vor der URL-Codierung 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
Create Signed Embed Url API-Endpunkt 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. Die generierte signierte URL muss genau kopiert werden und kann nur einmal verwendet werden. Andernfalls schlägt der Vorgang fehl. Der API Explorer ist auch nützlich, um eine signierte URL zu generieren und sie 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
Wenn Sie Ihre finale URL testen möchten, fügen Sie sie in den Embed URI Validator auf der Seite Einbetten im Bereich Administrator von Looker 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.