Mit der signierten Einbettung können Sie Ihren Nutzern private eingebettete Looks, Visualisierungen, explorative Datenanalysen, 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 teilen möchten, die ID des Nutzers in Ihrem System und die Berechtigungen, die der Nutzer haben soll. Sie signieren die URL dann mit einem von Looker bereitgestellten Secret-Schlüssel.
Informationen zur öffentlichen Einbettung finden Sie auf der Dokumentationsseite Öffentliche Freigabe, Import und Einbettung von Looks im Abschnitt Öffentliche Einbettung mit iframe
-Tags.
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 mit Einbettungen – 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 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 für die Einrichtung findest du auf der Dokumentationsseite Einbetten ohne Cookies.
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 über Domains hinweg zu authentifizieren, es sei denn, der Nutzer ändert die Cookie-Datenschutzeinstellungen seines Browsers. Wenn Sie beispielsweise Informationen auf https://mycompany.com
einbetten möchten, muss Looker dieselbe Domain verwenden, z. B. https://analytics.mycompany.com
. Wenn Ihre Instanz von Looker gehostet wird, wenden Sie sich an den Looker-Support, um die erforderliche DNS-Konfiguration einzurichten, damit die benutzerdefinierte Domain verwendet werden kann. So 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 verwendet wie Ihre Looker-Instanz.
Clientsichtbarkeit mit einem geschlossenen System steuern
Bei einer signierten Einbettungskonfiguration ist es üblich, dass Looker-Nutzer Daten für ihre eigenen Kunden präsentieren, während sie Kunden von verschiedenen Unternehmen oder Gruppen haben, die nichts voneinander wissen sollen. In diesem Fall empfehlen wir Ihnen dringend, Looker als geschlossenes System zu konfigurieren, auch Multi-Tenant-Installation genannt, um die privaten Daten Ihrer Kunden zu schützen. In einem geschlossenen System werden Inhalte in Silos zusammengefasst, um zu verhindern, dass sich Nutzer aus verschiedenen Gruppen untereinander kennen. 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 Embed-URL zu generieren. Sie haben folgende Möglichkeiten:
Sie können eine signierte Einbettungs-URL generieren. Klicken Sie dazu in einem Dashboard auf das Dreipunkt-Menü und wählen Sie Einbettungs-URL abrufen aus. Alternativ können Sie in einem Look oder Explore im Zahnradmenü für Explore-Aktionen die Option 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.
Code für die signierte Einbettungs-URL erstellen Um die richtige URL zu erstellen, müssen Sie Code schreiben, damit Sie die URL mit Ihrem geheimen Schlüssel richtig codieren und andere sicherheitsbezogene Elemente generieren können. Im GitHub-Repository für Looker-Beispiele zum Einbetten finden Sie mehrere Beispielscripts. In den folgenden Abschnitten wird erläutert, welche Informationen du für diese Scripts angeben musst und wie du eine signierte Embed-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
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, 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 |
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 in der Explore-URL auf den Parameter qid= folgen, bilden den 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 Wert Query.client_id der Abfragevisualisierung ab und kopieren Sie Query.client_id in die 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 hinzu oder geben Sie in der Dashboard-URL den Parameter hide_filter an, wenn Filterwerte ausgeblendet werden sollen. |
|
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 darf. Berechtigungen können auf zwei Arten angewendet werden:
- Modellspezifisch: Dieser Berechtigungstyp gilt nur für die Modellsätze, die zu derselben Rolle gehören.
- Instanzweit: Diese Art von Berechtigung gilt für die Looker-Instanz insgesamt. Embed-Benutzer mit instanzweiten Berechtigungen können bestimmte Funktionen in der gesamten Looker-Instanz ausführen, können jedoch nicht auf Inhalte auf der Grundlage von Modellen zugreifen, die nicht im Modellsatz ihrer Rolle enthalten sind.
Legen Sie fest, welche Berechtigungen 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 signiertes 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 kann LookML-Dashboards sehen |
see_looks |
access_data |
Modellspezifisch | Nutzer können Looks ansehen |
see_user_dashboards |
see_looks |
Modellspezifisch | Ermöglicht es Nutzern, benutzerdefinierte Dashboards aufzurufen und über eine Einbettung Ordner zu 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 | ADDED 22.4 Erforderlich, um benutzerdefinierte Felder in einem Explore zu erstellen |
can_create_forecast |
explore |
Instanzweit | HINZUGEFÜGT 22.12 Nutzer können 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 Nutzern, die Bereitstellung von Looker-Inhalten an einen beliebigen Webhook zu planen. |
send_to_s3 |
see_looks |
Modellspezifisch | Nutzer können Looker-Inhaltsübermittlungen an einen Amazon S3-Bucket 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 | Ermöglicht es Nutzern, die Zustellung von Looker-Inhalten an ihre eigene E-Mail-Adresse zu planen (falls mit einem Nutzerattribut namens „email“ festgelegt) 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 es Nutzern, die Zustellung von Looker-Inhalten an eine beliebige E-Mail-Domain zu planen. Nutzer mit der Berechtigung create_alerts können Benachrichtigungen an jede E-Mail-Domain senden. |
send_to_integration |
see_looks |
Modellspezifisch | Damit können Nutzer Looker-Inhalte über den Looker Action Hub an die mit Looker integrierten Dienste von Drittanbietern senden. 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 öffentlichen Benachrichtigungen anderer Nutzer bearbeiten, duplizieren und löschen. Wenn der Slack-Arbeitsbereich des Nutzers nicht mit der Looker-Instanz verbunden ist, kann er keine Benachrichtigungen erstellen, die an Slack gesendet werden. |
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 | Hier können Nutzer die SQL-Abfragen und alle SQL-Fehler sehen, die beim Ausführen von Abfragen auftreten. |
clear_cache_refresh |
access_data |
Modellspezifisch | HINZUGEFÜGT 21.14 Nutzer können den Cache leeren und eingebettete Dashboards, alte Dashboards, Dashboard-Kacheln, Looks und explorative Datenanalysen 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. Alle Nutzer, die die Berechtigung embed_browse_spaces haben, erhalten Zugriff auf einen persönlichen Ordner für eingebettete Inhalte und auf den Ordner Gemeinsam Ihrer Organisation, falls vorhanden. Die Berechtigung embed_browse_spaces wird für Nutzer empfohlen, die die Berechtigung save_content haben, damit sie Ordner durchsuchen können, wenn sie auswählen, wo sie Inhalte speichern möchten. 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 |
NEU 21.4
Nutzer, die auch die Berechtigung save_content haben, können im Dialogfeld Speichern zum Gemeinsam genutzten Ordner der Organisation wechseln, 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 keine Berechtigungen für den Inhaltszugriff. Damit Nutzer beispielsweise im Ordner Freigegeben Inhalte speichern können, benötigen sie weiterhin die Zugriffsrechte Zugriff verwalten, bearbeiten für den Ordner Freigegeben. Darüber hinaus hindert ein Nutzer mit der Berechtigung save_content und dem Zugriff Zugriff verwalten, bearbeiten auf den Freigegeben-Ordner nicht daran, Inhalte dort zu speichern, wenn er eine alternative Möglichkeit hat, zum Freigegeben-Ordner zu navigieren, z. B. über die Option Von hier aus analysieren in einem eingebetteten Dashboard.embed_save_shared_space |
Modellzugriff
Legen Sie fest, auf welche LookML-Modelle der Benutzer Zugriff haben soll. Es handelt sich dabei einfach um eine Liste mit 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
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. Angemeldete Nutzer mit eingebetteten Inhalten 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 nicht zu den regulären Looker-Gruppen gehört. 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 Nutzer erstellt, der den Code einbettet. 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 zusätzlich zu allen Rollen, die den im Parameter group_ids
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 kann der Nutzer, der die Daten einbettet, die Daten unter model_one
aufrufen und analysieren. Die mit den vorherigen Parametern erstellte Rolle für das Einbetten ermöglicht es ihm außerdem, die Daten unter model_two
aufzurufen.
Einbettungs-URL erstellen
Eine signierte Embed-URL hat folgendes Format:
https://HOST/login/embed/EINGEBENE URL?PARAMETER&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 bereits ermittelt. Sie hat ein Format wie dieses:
/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, fügen Sie am Ende der Einbettungs-URL eine embed_domain
(die Domain, in der der iFrame verwendet wird) hinzu. Das sieht dann so aus:
/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 bereits Parameter wie nonce=626
haben, würde die Hinzufügung 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 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
kann Looker erkennen, dass das SDK vorhanden ist, und zusätzliche Funktionen des SDKs 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 | Beliebiger Zufallsstring, der innerhalb einer Stunde nicht wiederholt werden darf und maximal 255 Zeichen lang 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 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. 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. 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. 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, dass Sie nicht dasselbe external_user_id für einen einzelnen Nutzer mit unterschiedlichen Berechtigungen, Nutzerattributwerten oder Modellzugriffen verwenden.Wenn dieselbe external_user_id für mehrere Nutzer oder für denselben Nutzer mit mehreren Berechtigungen, Nutzerattributen oder Modellsätzen verwendet wird, 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 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. Verwenden Sie anstelle von Gruppennamen Gruppen-IDs. | Stringarray | ["4", "3"] |
external_group_id |
"" | Eine eindeutige Kennung für die Gruppe, zu der der Nutzer in der Anwendung gehört, in der Looker eingebettet ist (optional).Nutzer, die zum Speichern von Inhalten berechtigt sind und eine externe Gruppen-ID haben, 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 ggf. haben sollte. Enthält eine Liste mit Namen von Nutzerattributen, gefolgt vom Wert des Nutzerattributs.Wenn Ihr LookML-Modell lokalisiert ist, können Sie 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 du das Feld leer lässt, wird für first_name der Wert der letzten Anfrage beibehalten. Andernfalls wird „Embed“ verwendet, wenn noch kein Vorname festgelegt wurde. |
JSON-String | "Alice" |
last_name |
"" | Der Nachname des Nutzers. Wenn Sie das Feld leer lassen, wird für last_name der Wert der letzten Anfrage beibehalten. Andernfalls wird „Embed“ verwendet, 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. Mit diesem Parameter wird nicht direkt die Zeitzone geändert, in der die Inhalte angezeigt werden. Der Nutzer muss eine Zeitzone aus dem Drop-down-Menü auswählen.Gültige Werte findest du auf der Dokumentationsseite Referenz für Zeitzonen bei signierten 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:?query_timezone=user_timezone 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 bei Looker angemeldet ist und ein signiertes eingebettetes Element anzeigt, können Sie Folgendes festlegen:1) Sie sollten sich den Artikel mit ihren aktuellen Anmeldedaten ansehen.oder2) 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 das richtige Einbettungs-Secret zum Generieren der Signatur in der Einbettungs-URL 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 dass die Einbettungs-URL 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:
- 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)
- Host gefolgt von
- Alle Werte außer Host und Einbettungs-URL als JSON formatieren
- Werte mit Zeilenumbrüchen (
\n
) verknüpfen - Signieren Sie den zusammengesetzten String mit dem geheimen Schlüssel für die Looker-Embedding-Funktion mit HMAC-SHA1.
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/
in Ihrer URL korrekt.
Nach der Codierung 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 „Create Signed Embed Url“ verwenden
Die Looker API enthält den Endpunkt Create Signed Embed Url (Signierte Einbettungs-URL erstellen). Er nimmt eine Reihe von signierten Einbettungsparametern mit der URL der Inhalte an, die Sie einbetten möchten, und gibt eine vollständige, codierte, kryptografisch signierte URL zurück.
Damit dieser API-Endpunkt von einem Webserver verwendet werden kann, muss sich der Webserver mit Administratorberechtigungen in 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-Marktplatz in Ihrer Looker-Instanz installieren. Nach der Generierung muss die signierte URL genau kopiert werden und kann nur einmal verwendet werden. Andernfalls schlägt die Übertragung fehl. Der APIs Explorer eignet sich auch zum Generieren einer signierten URL und zum Vergleichen mit einer manuell erstellten signierten URL zur Fehlerbehebung.
Weitere Informationen zur Looker API finden Sie auf der Dokumentationsseite Einstieg in die Looker API.
Einbettungs-URL testen
Um die finale URL zu testen, fügen Sie sie in den Embed URI Validator auf der Seite Embed im Bereich Verwaltung von Looker 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.