Sicherheit auf Zeilenebene für eingebettete Looker-Inhalte implementieren

Autor: Christopher Seymour, Senior Data Analyst, und Dean Hicks, Developer Relations Engineer

Einleitung

Die Einbettungsfunktion von Looker ist eine der leistungsstärksten und wertvollsten Funktionen des Looker-Produkts. Wenn Sie diesen Leitfaden lesen, ist es wahrscheinlich, dass Sie bereits Looker-Inhalte in Ihre Anwendung einbetten oder dies in naher Zukunft tun möchten.

Dieser Leitfaden soll Ihnen helfen, das Design der Einbettungsfunktion von Looker besser zu verstehen, damit Sie eine leistungsstarke und sichere Anwendung erstellen können, um Daten an Ihre Benutzer zu liefern. Ein tiefer Einblick in das Thema ist etwas langwierig. Denken Sie also daran, dass dieser Leitfaden keine schnelle Lösung für ein einfaches Problem ist, sondern einen Baustein, mit dem Sie Ihren gesamten Anwendungsfall für die Einbettung von Looker besser verwalten können.

Übersicht über die Anwendungsfälle

In diesem Leitfaden wird ein häufiger Anwendungsfall beschrieben, bei dem Ihr Unternehmen Looker-Inhalte in Ihr Produkt einbettet.

Gehen Sie für diesen Anwendungsfall für signierte Einbettungen davon aus, dass Sie der Administrator Ihrer Looker-Instanz sind. Sie verwenden zwei Arten von eingebetteten Nutzern: Kunden (oder „Markennutzer“), die nur auf Daten ihres Unternehmens zugreifen können sollen, und Kontoinhaber, die auf die Daten mehrerer, bestimmter Kunden zugreifen können. Sie haben ein Dashboard mit einigen Kacheln, die Sie allen Kunden anzeigen, die Ihr Produkt verwenden. Das Dashboard muss jedoch automatisch für jeden Kunden gefiltert werden, damit die Dashboards nur die für diese Kundschaft spezifischen Daten anzeigen. In den Beispielen in diesem Dokument werden zwei fiktive Unternehmen verwendet: Hooli und Riesenfänger.

Sie haben eine Tabelle namens Produkte, die einige Produktmesswerte für verschiedene Marken enthält. Jede Marke entspricht einem anderen eingebetteten Nutzer (mit einem anderen external_user_id) in der signierten Einbettungsanwendung. Da jeder eingebettete Nutzer nur die Daten für seine eigene Marke sehen sollte, haben Sie ein einfaches Explore mit einem Zugriffsfilter für ein brand-Nutzerattribut:

explore: products {
  access_filter: {
    field: products.brand
    user_attribute: brand
  }
}

Sie haben ein einfaches Dashboard, das auf diesem Explore basiert und zwei Kacheln hat: Eine zeigt den Namen der Marke, die andere die Anzahl der Produkte für diese Marke an.

Mit dem Endpunkt create_sso_embed_url generierst du Einbettungs-URLs dieses Dashboards für jeden eingebetteten Nutzer. In diesem Beispiel werden zwei Marken verwendet: Rattenfänger und Hooli. Hier ist der Anfragetext, den du im create_sso_embed_url-Aufruf für Rattenfänger mit external_user_id pied_piper verwendest:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "pied_piper",
  "first_name": "PiedPiper",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper"}
}

Die URL, die du für Piper-Piper generiert hast, zeigt das Dashboard wie folgt an:

Hier ist der Anfragetext, der im create_sso_embed_url-Aufruf für Hooli verwendet wird, mit external_user_id hooli:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "hooli",
  "first_name": "Hooli",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Hooli"}
}

Die für Hooli generierte URL zeigt das Dashboard folgendermaßen an:

Voilà! Das Dashboard wird nach dem Wert des eingebetteten Nutzers für das Nutzerattribut brand gefiltert.

Weitere Informationen

Sehr gut! Was aber, wenn ich einem Kontoinhaber Zugriff auf mehrere Marken gewähren möchte? Wie kann ich dafür sorgen, dass meine Daten nur relevanten Nutzern angezeigt werden?

Gute Neuigkeiten! Die signierte Einbettungsfunktion von Looker wurde entwickelt, um Entwicklern die Erstellung leistungsstarker, maßgeschneiderter Datenerlebnisse für Benutzer zu ermöglichen und gleichzeitig sicherzustellen, dass die von Ihrem Datenmodell und den Richtlinien für den Zugriff auf Inhalte definierte Data Governance eingehalten wird.

Für eine leistungsstarke Datenerfahrung ist es von entscheidender Bedeutung, sicherzustellen, dass Data Governance auf eine möglichst enge Governance ausgelegt ist. Lesen Sie weiter, um einige Konzepte und Best Practices kennenzulernen, mit denen Sie die Umgebung so gestalten können, dass sie für Sie am besten funktioniert. Zunächst geben wir einen kurzen Überblick darüber, wie all dies funktioniert.

Grundlagen der von Looker signierten Einbettung

Bitte beachten Sie, dass die Benutzerauthentifizierung und -verwaltung von Looker im Einbettungskontext im Grunde genauso funktioniert wie im Nicht-Einbettungskontext und im Wesentlichen genauso wie die meisten anderen Webanwendungen.

Dies kann im von Looker signierten Einbettungskontext verwirrend sein, da der signierte Authentifizierungsschritt, die Nutzereinstellungen und das Dashboard selbst zu einer langen, komplexen URL zusammengefasst werden. Diese URL wird jedoch verwendet, um die Sitzung einzurichten. Dies gilt auch nach der Kürzung der URL. Wenn Sie dieses Konzept im Hinterkopf behalten, wird Ihr Erfolg beim Erstellen großartiger Datenerfahrungen erheblich verbessert.

Struktur der signierten Einbettungs-URL

Hier siehst du eine der signierten URLs zur Authentifizierung zur Einbettung, die durch den create_sso_embed_url-Aufruf mit dem Anfragetext für Pied Piper generiert wurden:

https://mylookerinstance.cloud.looker.com/login/embed/%2Fembed%2Fdashboards%2F17?permissions=%5B%22access_data%22%2C%22see_user_dashboards%22%5D&models=%5B%22thelook%22%5D&signature=iG6vcKBgnA50jaL2iShFeQHwFPN7wvTx7Rz6r%2FtFuvE%3D&nonce=%22967729518a7dbb8a178f1c03a3511dd1%22&time=1696013242&session_length=300&external_user_id=%22pied_piper%22&access_filters=%7B%7D&first_name=%22Pied%22&last_name=%22Piper%22&user_attributes=%7B%22brand%22%3A%22Pied+Piper%22%7D&force_logout_login=true

Hier noch einmal dieselbe URL decodiert und in einzelne Zeilen aufgeschlüsselt:

https://mylookerinstance.cloud.looker.com/login/embed/
/embed/dashboards/17
?permissions=["access_data","see_user_dashboards"]
&models=["thelook"]
&signature=iG6vcKBgnA50jaL2iShFeQHwFPN7wvTx7Rz6r/tFuvE=
&nonce="967729518a7dbb8a178f1c03a3511dd1"
&time=1696013242
&session_length=300
&external_user_id="pied_piper"
&access_filters={}
&first_name="PiedPiper"
&last_name="User"
&user_attributes={"brand":"Pied Piper"}
&force_logout_login=true

Wenn Sie auf diese URL zugreifen, passiert Folgendes:

  1. Looker sucht nach einem vorhandenen Nutzerkonto mit external_user_id = pied_piper. Wenn keines vorhanden ist, erstellt Looker ein neues Nutzerkonto mit dieser external_user_id.

  2. Die Kontodetails des vorhandenen Nutzers werden mit den Kontodetails überschrieben, die in der URL angegeben sind. Dazu gehören Berechtigungen, Modelle, Gruppen (falls angegeben) und Nutzerattributwerte (falls angegeben).

  3. Looker authentifiziert den Nutzer und richtet eine Sitzung für diesen Nutzer ein, indem ein Sitzungscookie im Browser gespeichert wird.

  4. Looker leitet dann an die Ziel-URL oder Weiterleitungs-URL weiter, die im create_sso_embed_url-Aufruf angegeben ist:

    https://mylookerinstance.cloud.looker.com/embed/dashboards/17.

    Sie können diese Weiterleitungs-URL als codierte relative URL in der ursprünglichen signierten Einbettungs-URL sehen:

    %2Fembed%2Fdashboards%2F17

Die Schritte 1 bis 3 werden automatisch im Hintergrund ausgeführt und der Endnutzer sieht nur das Endergebnis (das Dashboard selbst), diese Schritte sind jedoch im Wesentlichen mit den Schritten identisch, bei denen sich ein regulärer Looker-Nutzer ohne eingebettetes Konto authentifiziert. Angenommen, Sie möchten, dass sich ein Nutzer mit Nutzer- und Passwortanmeldedaten anmeldet. Der Vorgang würde in etwa so aussehen:

  1. Sie (der Looker-Administrator) gehen zum Bereich „Admin – Benutzer“ und verwenden die Suchleiste, um zu prüfen, ob für diesen Nutzer bereits ein Nutzerkonto vorhanden ist. Wenn nicht, erstellen Sie ein neues Nutzerkonto.

  2. Sie (der Looker-Administrator) klicken im Bereich „Admin – Nutzer“ neben dem Nutzer auf Bearbeiten und stellen dem Nutzer Berechtigungen, Modelle, Gruppen, Nutzerattributwerte und andere Werte bereit.

  3. Der Nutzer ruft die Anmeldeseite unter https://mylookerinstance.cloud.looker.com/login auf und gibt seinen Nutzernamen und sein Passwort ein. Looker authentifiziert den Nutzer und richtet eine Sitzung für diesen Nutzer ein, indem ein Sitzungscookie im Browser gespeichert wird.

  4. Looker leitet dann auf die Landingpage weiter (in der Regel https://mylookerinstance.cloud.looker.com/browse).

Beachten Sie, dass das Sitzungscookie für jeden Tab im Browserfenster gilt. Wenn der Nutzer mit https://mylookerinstance.cloud.looker.com/browse startet, einen neuen Browsertab öffnet und eine beliebige Seite aufruft, auf die er über seine Berechtigungen zugreifen kann, wird die Seite wie erwartet geladen. Dabei wird das Sitzungscookie verwendet, das bereits auf dem ursprünglichen Browsertab festgelegt ist.

Dasselbe gilt für Nutzer von eingebetteten Inhalten. Für eingebettete Nutzer ist der Zugriff auf die Seiten in der Benutzeroberfläche etwas eingeschränkt – sie können nur auf Look-, Dashboard- und Explore-URLs mit dem Präfix /embed zugreifen. Sie können jedoch weiterhin manuell zu jedem Dashboard navigieren, auf das sie anhand ihrer Benutzerkontodetails Zugriff erhalten. Angenommen, die ursprüngliche signierte Einbettungs-URL leitet dich in einem Browsertab zu https://mylookerinstance.cloud.looker.com/embed/dashboards/17 weiter. Dann öffnen Sie einen neuen Browsertab und laden ein anderes eingebettetes Dashboard, das sich im selben Ordner befindet und daher dieselben Zugriffsbeschränkungen hat: https://mylookerinstance.cloud.looker.com/embed/dashboards/19.

Die Weiterleitungs-URL, die in der ursprünglichen signierten Einbettungs-URL angegeben wurde, war zwar für Dashboard 17 bestimmt, Sie können jedoch sehen, dass Dashboard 19 wie erwartet geladen wird, wenn Sie die URL manuell in einen Browsertab eingeben. Zum Laden eines anderen Dashboards war keine andere signierte Einbettungs-URL erforderlich.

Die wichtigste Erkenntnis hierbei ist, dass alle in der URL festgelegten Nutzerkontendetails (Berechtigungen, Nutzerattribute usw.) auf die gesamte Nutzersitzung angewendet werden und nicht nur auf das Dashboard, das in der ursprünglichen signierten URL angegeben ist. Mit anderen Worten, wie der Name schon sagt, sind Benutzerattribute eine Funktion der Nutzenden und keine Funktion des Dashboards. Sie sollten verwendet werden, um die Zugriffsebenen eines bestimmten Nutzers in der gesamten Anwendung und nicht nur in einem bestimmten Tab zu bestimmen.

Anwendungsfall: Kontoinhaber

Wie bei jeder anpassbaren Lösung gibt es auch hier bestimmte Ansätze, die Sie vermeiden sollten. Bedenken Sie deshalb, dass Sie auch Kontoinhaber haben, die möglicherweise mehrere Marken besitzen oder verwalten. In diesem Beispiel verwaltet ein Kontoinhaber sowohl die Marken Rattenfänger als auch die Marken Hooli. Daher generiert deine App die URLs für beide external_user_ids mit denselben Eingaben im zuvor gezeigten create_sso_embed_url-Aufruf und erstellt einen neuen Tab in der App, um jedes Dashboard zu laden, auf das der Kontoinhaber zugreifen möchte. Häufig haben Entwickler Lösungen wie diese implementiert, was zu einem falschen Workflow für Nutzer führt:

  1. Navigieren Sie zum Dashboard-Tab im Rattenfänger.
  2. Gehen Sie zum Tab „Hooli“-Dashboard.
  3. Gehe zurück zum Dashboard-Tab im Rattenfänger.
  4. Klicke auf dem Dashboard im Rattenfänger auf die Schaltfläche Aktualisieren.

...im Rattenfänger-Dashboard werden die Hooli-Daten angezeigt.

Sie können einen ähnlichen Ansatz ausprobieren, aber stattdessen denselben external_user_id test_user für beide create_sso_embed_url-Aufrufe verwenden:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper"}
}

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Hooli"}
}

Aber das Verhalten ist genau das Gleiche: Sobald der Tab mit dem Rattenfänger-Dashboard neu geladen wird, werden stattdessen die Daten für Hooli angezeigt.

Was ist hier los? Wie kann ich dafür sorgen, dass auf dem Dashboard jeder Marke nur die Daten für diese Marke angezeigt werden?

Derselbe Ansatz aus Sicht ohne Einbettung

Wie im vorherigen Abschnitt erläutert, funktionieren Nutzersitzungen mit signierten Einbettungen im Wesentlichen wie normale Looker-Nutzersitzungen ohne Einbettung. Daher kann es hilfreich sein, den zuvor beschriebenen problematischen Ansatz in eine reguläre Looker-Nutzersitzung ohne Einbettung zu unterteilen und diese Schritte aufzuschlüsseln, um zu verstehen, wie diese Lösung auf robustere Weise implementiert werden kann. So würde dieser Workflow aussehen, wenn Sie einem BI-Standardbenutzer Anweisungen geben würden, die Zugriff auf die Looker-Benutzeroberfläche haben:

  1. Zwei verschiedene Nutzerkonten werden auf der Seite „Verwaltung“ und „Nutzer“ erstellt.
    1. Legen Sie auf der Bearbeitungsseite des ersten Nutzerkontos den Wert des Nutzerattributs brand auf pied_piper fest.
    2. Legen Sie auf der Bearbeitungsseite für das zweite Nutzerkonto den Wert des Nutzerattributs brand auf hooli fest.
  2. Sie senden E-Mails zur Kontoeinrichtung für beide Nutzerkonten an den Kontoinhaber.
  3. Der Kontoinhaber richtet für jedes Konto eigene Anmeldedaten (E-Mail-Adresse und Passwort) ein.
  4. Sie geben dem Kontoinhaber den Link zum Dashboard. (https://mylookerinstance.cloud.looker.com/dashboards/17) und bitte ihn, das Dashboard zwischen Marken zu wechseln, indem er zur Anmeldeseite in einem anderen Tab zurückkehrt, die E-Mail-Adresse und das Passwort für das andere Nutzerkonto eingibt und das Dashboard dann noch einmal über diesen Tab laden muss.

Der Kontoinhaber folgt der Anleitung. Nachdem er jedoch den Nutzernamen und das Passwort des Hooli-Nutzerkontos auf dem zweiten Browsertab eingegeben und dann zum ersten Tab zurückgekehrt ist, auf dem das Rattenfänger-Dashboard bereits geladen war, klickt der Kontoinhaber auf die Schaltfläche Aktualisieren. Zur Überraschung des Kontoinhabers werden im Dashboard die Hooli-Daten angezeigt. Dies sollte keine Überraschung sein, da das gleiche Szenario genau im Kontext einer eingebetteten Inhalte gezeigt wird.

Sie können die zweite Implementierung auf die gleiche Weise schnell aufschlüsseln (denselben external_user_id test_user mit unterschiedlichen Nutzerattributen verwenden). Das UI-Äquivalent dieses Workflows sieht so aus:

  1. Sie erstellen ein Nutzerkonto für den Kontoinhaber.
  2. Sie legen pied_piper als Attributwert brand für dieses Nutzerkonto fest.
  3. Sie teilen dem Kontoinhaber mit, dass er sich für die Umstellung des Dashboards von Pied Piper auf Hooli an Sie wenden muss, damit Sie die Bearbeitungsseite für dieses Nutzerkonto aufrufen und den Attributwert brand von pied_piper in hooli ändern können.
  4. Nachdem Sie ihr Benutzerattribut bearbeitet haben, kann sie das Dashboard in einem neuen Tab wieder laden, um die Hooli-Daten zu sehen.

Sie denken jetzt vielleicht:

Moment ... das sieht nach einer Menge Arbeit aus! Gibt es nicht eine Möglichkeit, dem Nutzer ein einzelnes Nutzerkonto zuzuweisen und ihm zu ermöglichen, die Daten auf dem Dashboard diskret für jede Marke zu filtern?

Da ist es ja! Diese Szenarien veranschaulichen ein Prinzip, das im Kontext ohne Einbettung bereits einfach ist, aber durch die Abstraktionen des Einbettungskontexts verschleiert werden kann: Ein einzelner menschlicher Nutzer sollte einem einzelnen Looker-Nutzerkonto mit einem einzigen Satz von Nutzerattributwerten zugeordnet werden. Dies wird auch in unserer Erläuterung der external_user_id in unserer Dokumentation zu signierten Einbettungen verdeutlicht.

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.

Diese Best Practices

Wenn wir diese Prinzipien auf unser Beispiel anwenden, benötigen Sie einen einzelnen Nutzerattributwert, der Zugriff auf ALLE Daten gewährt, auf die der Kontoinhaber in der Anwendung Zugriff haben sollte. Verwenden Sie dazu einen kommagetrennten Wert für das Attribut brand [Marke] Pied Piper,Hooli:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper,Hooli"}
}

Damit diese Syntax funktioniert, muss Ihr Nutzerattribut als Stringfilter (erweitert) festgelegt sein:

Hinweis: Sie können die Gruppe der Nutzerattribute für einen Nutzer auch ändern, wenn sich an seinen Datenzugriffsebenen etwas ändert. Wenn beispielsweise der Kontoinhaber die Inhaberschaft einer dritten Marke übernimmt, können Sie diese Marke der durch Kommas getrennten Liste hinzufügen, die Sie für das Nutzerattribut brand angegeben haben. Auf diese Weise werden die Änderungen übernommen, wenn er sich ab- und wieder anmeldet.

Dashboardergebnisse filtern

Ich verstehe, dass die Nutzerattribute alle Daten angeben müssen, auf die ein Nutzer in der Anwendung zugreifen kann. Wenn ich die Benutzerattribute jedoch auf diese Weise angebe, werden die Daten für all diese Marken in meinem Dashboard angezeigt. Wie kann ich die Ergebnisse in einem bestimmten Dashboard auf eine bestimmte Marke eingrenzen?

Um ein bestimmtes Dashboard zu filtern, verwenden Sie die regulären Dashboard-Filter. (Das mag jetzt offensichtlich erscheinen, aber wir haben festgestellt, dass einige Nutzer bei Nutzerattributen feststecken, die die einzige Möglichkeit sind, Filter im Einbettungskontext anzuwenden – vielleicht, weil user_attributes ein Parameter in der signierten Einbettungs-URL ist, Filter aber nicht.)

Sie müssen einen Filterwert angeben und eine der Optionen für die Einzelauswahl verwenden, z. B. ein Drop-down-Menü:

Stellen Sie sicher, dass der Filter auf allen erforderlichen Kacheln auf das richtige Feld angewendet wird:

Jetzt kann der Kontoinhaber zwischen diesen beiden Werten wählen, da die verfügbaren Optionen im Drop-down-Menü durch die Nutzerattribute eingeschränkt sind:

Dashboard-Filter vorab ausfüllen

Das Dashboard kann jetzt nach einer bestimmten Marke gefiltert werden. Der Filterwert soll aber bereits auf eine bestimmte Marke festgelegt sein, wenn der Nutzer das Dashboard für diese Marke in meiner App lädt.

Auch hier ist es hilfreich, darüber nachzudenken, wie dies im Kontext ohne Einbettung funktioniert. Wie senden Sie jemandem einen Link zu einem Dashboard, auf das bereits ein bestimmter Filterwert angewendet wird? Sie haben vielleicht bemerkt, dass nach der Auswahl eines Filterwerts dieser Filterwert in der URL für das Dashboard angezeigt wird:

Fügen Sie diesen Teil der URL in die Datei target_url für den create_sso_embed_url-Aufruf ein:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17?Brand=Hooli",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper,Hooli"}
}

Wenn Sie das Embed SDK verwenden, können Sie mit withFilters anfängliche Filter angeben, die auf die eingebetteten Inhalte angewendet werden sollen:

https://looker-open-source.github.io/embed-sdk/classes/EmbedBuilder.html#withFilters

Wenn Sie Ihr eigenes benutzerdefiniertes Skript verwenden, sollten Sie sicherstellen, dass Sie den Filter zur URL hinzufügen, bevor der Pfad codiert wird. Einige Werte sind im Filterstring möglicherweise bereits codiert (in ?Brand=Pied+Piper ist ein Leerzeichen als + codiert). Diese Werte werden dann in der finalen URL doppelt codiert. Weitere Informationen finden Sie im Abschnitt So eingebettetes Dashboard – Dashboard-Filter als Teil der URL festlegen?. Looker-Community-Beitrag zur Diskussion dieser Nuancen. Wenn du immer noch Probleme beim Anwenden der Filter hast, kannst du in diesem Communitybeitrag auch Fragen hinzufügen.

Dashboardfilter ausblenden

Ich verstehe, wie die anfänglichen Filter in meinen Dashboards festgelegt werden, aber ich möchte auch nicht, dass der Kontoinhaber die Dashboard-Filter selbst ändert. Der Filterwert sollte NUR dadurch bestimmt werden, welches Dashboard der Kontoinhaber in meiner App aufgerufen hat. Wie kann ich die Dashboard-Filter ausblenden?

Dazu können Sie Designs verwenden. Designs sind eine kostenpflichtige Funktion. Wenn Sie diese Funktion nicht bereits auf Ihrer Looker-Instanz aktiviert haben, wenden Sie sich an Ihr Looker-Vertriebsteam.

Wenn diese Funktion aktiviert ist, gehen Sie auf der Seite „Verwaltung“ – Designs zum Abschnitt Dashboard-Steuerelemente. Dort können Sie die Option Filterleiste anzeigen entfernen:

Anschließend können Sie entweder Ihr Design als Standard festlegen oder das Design in der URL Ihrer spezifischen Dashboards anwenden. Auch dies würde in den target_url des create_sso_embed_url-Aufrufs eingefügt werden:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17?Brand=Hooli&theme=test_theme",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper,Hooli"}
}

Weitere Informationen zum Ausblenden von Dashboard-Einbettungsfiltern, einschließlich einiger Einbettungs-SDK-Code-Snippets, finden Sie in dieser YouTube-Anleitung zum Einbetten von Looker mit benutzerdefinierten Filtern.

Das Endergebnis sollte genauso aussehen wie bei der ursprünglichen Frage:

Da die Filterwerte jedoch in den entsprechenden Ziel-URLs codiert sind, die in die App eingebettet sind, wird auf dem Dashboard der einzelnen Marken immer das für die richtige Marke gefilterte Dashboard angezeigt, selbst wenn Sie zwischen Tabs hin- und herwechseln.

Sudo wie andere Nutzer erstellen

Jetzt entspricht die Nutzererfahrung sehr stark dem, was ich ursprünglich gedacht hatte. In meinem Anwendungsfall hat der Kontoinhaber aber andere Berechtigungen und andere Nutzereinstellungen als die einzelnen Nutzer mit external_user_id=pied_piper und external_user_id=hooli. Das führt zu unterschiedlichen verfügbaren Optionen in der Benutzeroberfläche und zu einer etwas anderen Nutzererfahrung. Ich möchte, dass der Kontoinhaber alles genau so sieht, wie es pied_piper und pied_piper die Nutzer sehen, so als ob der Kontoinhaber sich tatsächlich als diese Nutzer angemeldet hätte. Wie kann ich das erreichen?

Ihre Anfrage lautet „sudo“. Wenn Sie möchten, dass Ihr Kontoinhaber in der Lage sein soll, als einzelner Markennutzer „sudo“ zu verwenden, können Sie eine ähnliche sudo-Funktion in Ihrer App erstellen, die die Einbettungs-URLs für external_user_id=pied_piper lädt, wenn der Kontoinhaber im Sudo als Pied Piper-Nutzer verwendet, und die Einbettungs-URLs für external_user_id=hooli, wenn der Kontoinhaber im Sudo als Hooli-Nutzer arbeitet. Sie können den login_user API-Endpunkt auch verwenden, um als Brand-Nutzer mit der API im Sudo zu arbeiten, wenn Ihre App die API verwendet.

Wenn Sie jedoch noch einmal an den Kontext ohne Einbettung denken: Auf der Seite „Admin - Users“ können Sie nicht gleichzeitig als mehrere Nutzer, die nicht eingebettet sind, auf mehreren Tabs „sudo“ ausführen. Die sudo-Sitzung gilt wie alle anderen Benutzersitzungen für das gesamte Browserfenster. Daher sollten Sie sudo zu sudo immer nur als ein Benutzer auf einmal entwerfen. Und wenn Sie darüber nachdenken, ist dieses Design einheitlicher, da es die User Experience der Nutzenden, für die Sie Sudo-Funktionen nutzen, perfekt nachahmt. Der Nutzer pied_piper hat beispielsweise nur Zugriff auf das Pied-Piper-Dashboard und nicht, um zusätzliche Dashboards in weiteren Tabs zu öffnen. Daher sollten Sie auch keine verschiedenen Dashboards in verschiedenen Tabs öffnen können, wenn Sie als dieser Benutzer Sudo verwenden.

Fazit

Wir hoffen, dass Sie diesen Leitfaden hilfreich fanden und gut auf die Erstellung Ihrer von Looker signierten Einbettungsinhalte vorbereitet sind. Wir arbeiten kontinuierlich daran, Looker zum flexibelsten und robustesten Angebot für eingebettete Datenanalysen zu machen, und würden uns über Ihr Feedback freuen! Wenn Sie Fragen haben oder mehr erfahren möchten, können Sie sich in der Looker-Community an uns wenden und an unseren Community-Veranstaltungen teilnehmen.