Segmentierung auf Zeilenebene für eingebettete Looker-Inhalte implementieren

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

Mit der Segmentierung auf Zeilenebene können Sie den Datenzugriff einzelner Nutzer auf Grundlage der in einem oder mehreren Datenbankfeldern gespeicherten Werte einschränken. In diesem Leitfaden werden Methoden zur Implementierung der Segmentierung auf Zeilenebene in eingebetteten Looker-Inhalten beschrieben. Er enthält die folgenden Abschnitte:

Einführung

Die Einbettungsfunktion von Looker ist eine der leistungsstärksten und wertvollsten Funktionen des Looker-Produkts. Wenn Sie diesen Leitfaden lesen, betten Sie wahrscheinlich bereits Looker-Inhalte in Ihre Anwendung ein oder haben vor, dies in naher Zukunft zu tun.

In dieser Anleitung erfahren Sie mehr über das Design der Looker-Einbettungsfunktion und wie Sie die Segmentierung in einer Anwendung implementieren, in der Partner den Zugriff auf mehrere Marken verwalten können. Da es sich um eine ausführliche Anleitung handelt, ist sie etwas länger. Sie ist nicht als schnelle Lösung für ein einfaches Problem gedacht, sondern als Baustein, mit dem Sie Ihren gesamten Looker-Einbettungsanwendungsfall besser verwalten können.

Übersicht über Anwendungsfälle

In diesem Leitfaden wird ein häufiger Anwendungsfall beschrieben, in dem Ihr Unternehmen Looker-Inhalte in Ihr Produkt einbettet und Segmente von Nutzern bedient, die unterschiedliche Ausschnitte Ihrer Daten sehen sollen.

In diesem Anwendungsfall für signierte Einbettungen wird davon ausgegangen, dass Sie der Administrator Ihrer Looker-Instanz sind. Sie arbeiten mit zwei Arten von externen eingebetteten Nutzern: Kunden, die nur auf Daten zugreifen können, die sich auf ihre jeweilige Marke beziehen, und Partner, die auf Daten für mehrere Marken zugreifen können. Sie haben ein Dashboard mit einigen Kacheln, das Sie jedem Kunden zeigen, der Ihr Produkt verwendet. Das Dashboard muss jedoch für jeden Kunden automatisch gefiltert werden, damit nur die Daten angezeigt werden, die für diesen Kunden spezifisch sind. In den Beispielen in diesem Dokument werden zwei fiktive Unternehmen verwendet: Hooli und Pied Piper.

Sie haben eine Tabelle mit dem Namen products, in der einige Produktmesswerte für verschiedene Marken aufgeführt sind. Jede Marke entspricht einem anderen Nutzer mit eingebettetem Inhalt (mit einer anderen external_user_id) in der signierten Anwendung mit eingebettetem Inhalt. Da jeder eingebettete Nutzer nur die Daten für seine eigene Marke sehen soll, haben Sie einen Explore, in dem ein Zugriffsfilter für das Nutzerattribut brand verwendet wird:

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

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

Sie verwenden den Endpunkt create_sso_embed_url, um für jeden eingebetteten Nutzer Einbettungs-URLs für dieses Dashboard zu generieren. In diesem Beispiel werden zwei Marken verwendet: Pied Piper und Hooli. Hier ist der Anfragetext, den Sie im create_sso_embed_url-Aufruf für Pied Piper mit external_user_id pied_piper verwenden:

{
  "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 Sie für Pied Piper generiert haben, zeigt das Dashboard so an:

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

{
  "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 so an:

Voilà: Das Dashboard wird entsprechend dem Wert des Nutzerattributs Marke für jeden eingebetteten Nutzer gefiltert.

Weitere Informationen

Sehr cool! Was ist, wenn ich einem einzelnen Nutzer Zugriff auf mehrere Marken gewähren möchte? Wie kann ich dafür sorgen, dass meine Daten nur von relevanten Nutzern gesehen werden?

Gute Neuigkeiten! Die Funktion für signierte Einbettungen von Looker wurde entwickelt, damit Entwickler leistungsstarke, benutzerdefinierte Datenfunktionen für Nutzer erstellen können. Gleichzeitig wird dafür gesorgt, dass die in Ihrem Datenmodell und Ihren Richtlinien für den Zugriff auf Inhalte definierte Data Governance eingehalten wird.

Eine lückenlose Data Governance ist unerlässlich, um diese leistungsstarke Datenumgebung zu schaffen. Im Folgenden finden Sie einige Konzepte und Best Practices, mit denen Sie die für Sie am besten geeignete Umgebung gestalten können. Zuerst erhalten Sie einen kurzen Überblick über die Funktionsweise.

Grundlagen der signierten Einbettung in Looker

Die Nutzerauthentifizierung und ‑verwaltung von Looker im Einbettungskontext funktioniert im Grunde genauso wie im Nicht-Einbettungskontext und wie bei den meisten anderen Webanwendungen.

Das kann im Kontext von signierten Looker-Einbettungen verwirrend sein, da der signierte Authentifizierungsschritt, die Nutzereinstellungen und das Dashboard selbst in einer langen, komplexen URL kombiniert werden. Diese URL wird jedoch verwendet, um die Sitzung einzurichten, was auch nach dem Kürzen der URL gilt. Wenn Sie dieses Konzept im Hinterkopf behalten, können Sie leichter ansprechende Datenanwendungen erstellen.

Struktur signierter Einbettungs-URLs

Hier ist eine der signierten Authentifizierungs-URLs für das Einbetten, die vom 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

So sieht dieselbe URL decodiert und in einzelne Zeilen aufgeteilt aus:

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. Falls keines vorhanden ist, wird in Looker ein neues Nutzerkonto mit dieser external_user_id erstellt.

  2. Die Kontodetails des vorhandenen Nutzers, einschließlich Berechtigungen, Modelle, Gruppen (falls angegeben) und Nutzerattributwerte (falls angegeben), werden mit den in der URL angegebenen Kontodetails überschrieben.

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

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

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

    Diese Weiterleitungs-URL ist in der ursprünglichen signierten Einbettungs-URL als codierte relative URL enthalten:

    %2Fembed%2Fdashboards%2F17

Die Schritte 1 bis 3 erfolgen zwar automatisch im Hintergrund und der Endnutzer sieht nur das Endergebnis (das Dashboard selbst), aber diese Schritte sind im Grunde dieselben wie die Schritte, mit denen sich ein regulärer Looker-Nutzer, der keine Einbettung verwendet, authentifiziert. Angenommen, ein Nutzer soll sich mit Nutzernamen und Passwort anmelden. Der Prozess würde in etwa so aussehen:

  1. Sie (der Looker-Administrator) rufen den Bereich „Admin“ – „Nutzer“ auf und prüfen über die Suchleiste, ob für diesen Nutzer bereits ein Nutzerkonto vorhanden ist. Andernfalls erstellen Sie ein neues Nutzerkonto.

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

  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 ihn ein, indem ein Sitzungscookie im Browser gespeichert wird.

  4. Looker leitet Sie dann zur Landingpage weiter (normalerweise https://mylookerinstance.cloud.looker.com/browse).

Das Sitzungscookie gilt für alle Tabs im Browserfenster. Wenn der Nutzer auf https://mylookerinstance.cloud.looker.com/browse beginnt, einen neuen Browsertab öffnet und zu einer beliebigen Seite navigiert, auf die er Zugriff hat, wird die Seite wie erwartet mit dem Sitzungscookie geladen, das bereits im ursprünglichen Browsertab eingerichtet wurde.

Das gilt auch für Nutzer, die Inhalte einbetten. Nutzer mit eingebetteten Konten haben etwas eingeschränkteren Zugriff auf die Seiten der Benutzeroberfläche. 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 aufgrund ihrer Nutzerkontodetails Zugriff haben. Angenommen, die ursprüngliche signierte Einbettungs-URL leitet Sie in einem Browsertab zu https://mylookerinstance.cloud.looker.com/embed/dashboards/17 weiter. Anschließend ö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.

Obwohl die in der ursprünglichen signierten Einbettungs-URL angegebene Weiterleitungs-URL für Dashboard 17 war, wird Dashboard 19 wie erwartet geladen, wenn Sie die URL manuell in einen Browser-Tab eingeben. Hinweis: Zum Laden eines anderen Dashboards war keine weitere signierte Einbettungs-URL erforderlich.

Wichtig ist hier, dass alle in der URL festgelegten Nutzerkontodetails (Berechtigungen, Nutzerattribute usw.) auf die gesamte Nutzersitzung angewendet werden, nicht nur auf das in der ursprünglichen signierten URL angegebene Dashboard. Wie der Name schon sagt, sind Nutzerattribute also eine Funktion des Nutzers, nicht des Dashboards. Sie sollten verwendet werden, um die Zugriffsebenen eines bestimmten Nutzers in der gesamten Anwendung zu bestimmen, nicht nur auf einem bestimmten Tab.

Gleichzeitiger Zugriff auf mehrere Marken

Denken Sie daran, dass Sie auch externe Partner haben, die möglicherweise mehrere Marken besitzen oder verwalten. In diesem Beispiel verwaltet ein Partner sowohl die Marke Pied Piper als auch die Marke Hooli.

Der Ansatz aus einer Perspektive ohne Einbettung

Signierte Einbettungssitzungen funktionieren im Grunde genauso wie reguläre Looker-Nutzersitzungen ohne Einbettung. Daher kann es hilfreich sein, den zuvor beschriebenen problematischen Ansatz im Kontext einer regulären Looker-Nutzersitzung ohne Einbettung zu betrachten und die Schritte aufzuschlüsseln, um die Implementierung dieser Lösung besser zu verstehen. So würde dieser Workflow aussehen, wenn Sie einem Standard-BI-Nutzer mit Zugriff auf die Looker-UI eine Anleitung geben:

  1. Sie erstellen zwei verschiedene Nutzerkonten auf der Seite „Admin“ – „Nutzer“.
    1. Auf der Bearbeitungsseite für das erste Nutzerkonto legen Sie den Wert des Nutzerattributs brand auf pied_piper fest.
    2. Legen Sie auf der Bearbeitungsseite für das zweite Nutzerkonto den Attributwert des Nutzerattributs brand auf hooli fest.
  2. Sie senden E-Mails zur Kontoeinrichtung für beide Nutzerkonten an den Partner.
  3. Der Partner richtet für jedes Konto separate Anmeldedaten (E‑Mail-Adresse und Passwort) ein.
  4. Sie geben dem Partner den Link zum Dashboard. (https://mylookerinstance.cloud.looker.com/dashboards/17) und weise ihn darauf hin, dass er zum Wechseln des Dashboards zwischen Marken in einem anderen Tab zur Anmeldeseite zurückkehren und die E-Mail-Adresse und das Passwort für sein anderes Nutzerkonto eingeben muss. Anschließend kann er das Dashboard in diesem Tab neu laden.

Der Partner folgt der Anleitung. Nachdem er jedoch den Nutzernamen und das Passwort des Hooli-Nutzerkontos auf dem zweiten Browser-Tab eingegeben und dann zum ersten Tab zurückgekehrt ist, auf dem das Pied Piper-Dashboard bereits geladen war, klickt er auf den Button Neu laden. Zur Überraschung des Partners werden auf dem Dashboard die Hooli-Daten angezeigt.

Sie denken jetzt vielleicht:

Warte… das ist sehr umständlich. Wie geht das am besten?

Ja. Diese Szenarien veranschaulichen ein Prinzip, das im Kontext ohne Einbettung bereits trivial ist, aber durch die Abstraktionen des Einbettungskontexts verdeckt werden kann: Ein einzelner menschlicher Nutzer sollte einem einzelnen Looker-Nutzerkonto mit einem einzelnen Satz von Nutzerattributwerten zugeordnet werden. Das wird auch in unserer Erklärung von external_user_id in der Dokumentation zur signierten Einbettung deutlich.

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. Während einer Sitzung können keine Änderungen an den Berechtigungen oder Nutzerattributen eines Nutzers vorgenommen werden.

Gleichzeitiger Zugriff auf mehrere Marken – was Sie NICHT tun sollten

Wie bei jeder anpassbaren Lösung gibt es bestimmte Ansätze, die Sie vermeiden sollten. Beispiel: Ihre App generiert 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 Partner zugreifen muss. Wir haben häufig gesehen, dass Entwickler Lösungen wie diese implementieren, was zu einem falschen Workflow für den Nutzer führt:

  1. Rufen Sie den Tab „Pied Piper-Dashboard“ auf.
  2. Rufen Sie den Tab „Hooli-Dashboard“ auf.
  3. Kehren Sie zum Tab mit dem Pied Piper-Dashboard zurück.
  4. Klicken Sie im Pied Piper-Dashboard auf die Schaltfläche Neu laden.

…im Pied Piper-Dashboard werden die Hooli-Daten angezeigt.

Sie könnten einen ähnlichen Ansatz versuchen, aber stattdessen denselben external_user_id test_user für beide create_sso_embed_url-Aufrufe verwenden. Das Verhalten ist jedoch genau dasselbe: Sobald der Tab mit dem Pied Piper-Dashboard neu geladen wird, werden die Daten für Hooli angezeigt.

Wie kann ich dafür sorgen, dass im Dashboard jeder Marke nur die Daten für diese Marke angezeigt werden?

Best Practices anwenden

Wenn Sie den im Abschnitt Der Ansatz aus einer nicht eingebetteten Perspektive beschriebenen Ansatz anwenden möchten, benötigen Sie einen einzelnen Attributwert, der Zugriff auf ALLE Daten gewährt, auf die der Partner in der gesamten Anwendung Zugriff haben soll. Dazu können Sie einen durch Kommas getrennten Wert für das Attribut brand verwenden: 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 String-Filter (erweitert) festgelegt sein:

Sie können die Nutzerattribute für einen Nutzer weiterhin ändern, wenn sich seine Datenzugriffsebenen ändern. Wenn der Partner beispielsweise die Inhaberschaft einer dritten Marke übernimmt, können Sie diese dritte Marke der kommagetrennten Liste hinzufügen, die Sie für das Nutzerattribut brand angegeben haben. Wenn sich der Nutzer ab- und wieder anmeldet, werden die Änderungen angewendet.

Dashboard-Ergebnisse filtern

Okay, ich verstehe, dass in den Nutzerattributen alle Daten angegeben werden müssen, auf die ein Nutzer in der gesamten Anwendung zugreifen kann. Wenn ich die Nutzerattribute auf diese Weise angebe, werden auf meinem Dashboard jedoch die Daten für alle diese Marken angezeigt. Wie kann ich die Ergebnisse eines bestimmten Dashboards auf eine bestimmte Marke eingrenzen?

Die richtige Methode zum Filtern eines bestimmten Dashboards sind die ganz normalen Dashboard-Filter. Das mag jetzt offensichtlich erscheinen, aber wir haben schon gesehen, dass einige Nutzer nur Nutzerattribute als Möglichkeit zum Anwenden von Filtern im Einbettungskontext in Betracht ziehen. Das liegt vielleicht daran, dass user_attributes ein Parameter in der signierten Einbettungs-URL ist, „filters“ aber nicht.

Achten Sie darauf, dass ein Filterwert erforderlich ist, und verwenden Sie eine der Steuerelementoptionen für die Einzelauswahl, z. B. Drop-down-Menü:

Prüfen Sie, ob der Filter auf allen erforderlichen Kacheln auf das richtige Feld angewendet wird:

Ihr Partner kann jetzt zwischen diesen beiden Werten auswählen, da die verfügbaren Optionen im Drop-down-Menü durch die Nutzerattribute eingeschränkt werden:

Dashboard-Filter vorab ausfüllen

Okay, das Dashboard kann jetzt nach einer bestimmten Marke gefiltert werden. Ich möchte aber, dass der Filterwert bereits auf eine bestimmte Marke festgelegt ist, wenn der Nutzer das Dashboard für diese Marke in meiner App lädt.

Auch hier ist es hilfreich, sich vorzustellen, wie das ohne Einbettung funktioniert. Wie senden Sie jemandem einen Link zu einem Dashboard, auf das bereits ein bestimmter Filterwert angewendet wurde? Wenn Sie einen Filterwert auswählen, wird dieser in der URL für das Dashboard angezeigt:

Fügen Sie diesen Teil der URL in Ihren target_url-Parameter 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 die anfänglichen Filter angeben, die auf die eingebetteten Inhalte angewendet werden sollen:

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

Wenn Sie ein eigenes benutzerdefiniertes Script verwenden, müssen Sie den Filter der URL hinzufügen, bevor der Pfad codiert wird. Einige Werte sind möglicherweise bereits im Filterstring codiert (z. B. ein Leerzeichen, das als „+“ in ?Brand=Pied+Piper codiert ist). Diese Werte werden in der endgültigen URL doppelt codiert. Weitere Informationen finden Sie im Hilfeartikel SO embedded dashboard - set dashboard filter as part of URL?. Weitere Informationen zu diesen Nuancen finden Sie im Looker-Communitybeitrag. Wenn du weiterhin Probleme hast, die Filter anzuwenden, kannst du dort auch Fragen stellen.

Dashboard-Filter ausblenden

Okay, ich weiß, wie ich die anfänglichen Filter für meine Dashboards festlege. Ich möchte aber auch nicht, dass der Partner die Dashboard-Filter selbst ändert. Der Filterwert soll NUR davon abhängen, zu welchem Dashboard der Partner in meiner App navigiert ist. Wie kann ich die Dashboard-Filter ausblenden?

Dazu können Sie Designs verwenden. Designs sind eine kostenpflichtige Funktion. Wenn sie in Ihrer Looker-Instanz noch nicht aktiviert sind, sollten Sie sich an Ihr Looker-Vertriebsteam wenden, um sie aktivieren zu lassen.

Sobald die Funktion aktiviert ist, rufen Sie auf der Seite „Admin – Designs“ den Bereich Dashboard-Steuerelemente auf und deaktivieren Sie die Option Filterleiste anzeigen:

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

{
  "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 Filtern in eingebetteten Dashboards, einschließlich einiger Code-Snippets für das Embed SDK, finden Sie in diesem YouTube-Tutorial: Looker mit benutzerdefinierten Filtern einbetten.

Das Endergebnis sollte mit der User Experience aus der ursprünglichen Frage identisch sein:

Da die Filterwerte jetzt in den jeweiligen Ziel-URLs codiert sind, die in die App eingebettet sind, wird im Dashboard jeder Marke immer das nach der richtigen Marke gefilterte Dashboard angezeigt, auch wenn Sie zwischen Tabs wechseln.

Als andere Nutzer testen

Die Nutzerfreundlichkeit entspricht jetzt fast genau dem, was ich mir ursprünglich vorgestellt hatte. In meinem Anwendungsfall hat der Partner jedoch 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 Optionen in der Benutzeroberfläche und insgesamt zu einer leicht abweichenden Nutzerfreundlichkeit. Ich möchte, dass ein Nutzer alles genau so sieht wie die Nutzer von pied_piper und hooli – so, als ob die Person sich tatsächlich als diese Nutzer angemeldet hätte. Wie kann ich das erreichen?

Wenn ein Nutzer die einzelnen Markenidentitäten testen soll, können Sie eine ähnliche Sudo-Funktion in Ihre App einbauen, die die Einbettungs-URLs für external_user_id=pied_piper lädt, wenn der Nutzer die Identität von Pied Piper annimmt, und die Einbettungs-URLs für external_user_id=hooli, wenn der Nutzer die Identität von Hooli annimmt. Wenn Ihre App die API verwendet, können Sie auch den login_user-API-Endpunkt verwenden, um die Identität des Markennutzers mit der API anzunehmen.

Wenn Sie jedoch noch einmal an den Nicht-Einbettungskontext denken: Auf der Seite „Admin – Nutzer“ können Sie nicht gleichzeitig in mehreren Tabs als mehrere Nicht-Einbettungsnutzer agieren. Die SUDO-Sitzung gilt für das gesamte Browserfenster, genau wie alle anderen Nutzersitzungen. Daher sollten Sie SUDO so gestalten, dass jeweils nur ein Nutzer verwendet wird. Und wenn Sie darüber nachdenken, ist dieses Design konsistenter, da es die Erfahrung der Nutzer, als die Sie agieren, perfekt nachahmt. Der Nutzer pied_piper hat beispielsweise nur Zugriff auf das Pied Piper-Dashboard und kann keine zusätzlichen Dashboards in zusätzlichen Tabs öffnen. Daher sollten Sie auch nicht in der Lage sein, verschiedene Dashboards in verschiedenen Tabs zu öffnen, wenn Sie als dieser Nutzer agieren.

Fazit

Wir hoffen, dass dieser Leitfaden hilfreich war und Sie sich gut vorbereitet fühlen, um mit der Entwicklung Ihrer signierten eingebetteten Looker-Inhalte fortzufahren. Wir arbeiten ständig daran, Looker zum flexibelsten und robustesten Angebot für eingebettete Datenanalysen zu machen, und freuen uns über Ihr Feedback. Wenn Sie Fragen haben oder mehr erfahren möchten, können Sie sich in der Looker-Community mit uns austauschen und an unseren Community-Veranstaltungen teilnehmen.