Von Christopher Seymour, Senior Data Analyst, und Dean Hicks, Developer Relations Engineer
Mit der Segmentierung auf Zeilenebene können Sie die Daten einschränken, auf die ein einzelner Nutzer zugreifen kann, basierend auf den Werten, die in einem oder mehreren Datenbankfeldern gespeichert sind. In diesem Leitfaden werden Methoden zur Implementierung der Segmentierung auf Zeilenebene in eingebetteten Looker-Inhalten beschrieben. Er enthält die folgenden Abschnitte:
- Einführung
- Grundlagen von signierten Looker-Embeds
- Gleichzeitiger Zugriff auf mehrere Marken
- Best Practices anwenden
- Fazit
Einführung
Die Embedding-Funktion von Looker ist eine der leistungsstärksten und nützlichsten Funktionen des Looker-Produkts. Wenn Sie diesen Leitfaden lesen, haben Sie wahrscheinlich bereits Looker-Inhalte in Ihre Anwendung eingebettet oder beabsichtigen dies in naher Zukunft.
In diesem Leitfaden erfahren Sie mehr über das Design der Einbettungsfunktion von Looker und darüber, wie Sie die Segmentierung in einer Anwendung implementieren, in der Partner den Zugriff auf mehrere Marken verwalten können. Da dieser Leitfaden einen detaillierten Einblick in das Thema bietet, ist er etwas länger. Beachten Sie, dass er nicht als schnelle Lösung für ein einfaches Problem gedacht ist, sondern als Baustein, mit dem Sie Ihren gesamten Looker-Embedding-Anwendungsfall besser verwalten können.
Anwendungsfall – Übersicht
In diesem Leitfaden wird ein gängiger Anwendungsfall beschrieben, bei dem Ihr Unternehmen Looker-Inhalte in Ihr Produkt einbettet und Segmente von Nutzern bedient, die unterschiedliche Datenansichten sehen sollen.
Angenommen, Sie sind der Administrator Ihrer Looker-Instanz. Sie arbeiten mit zwei Arten von externen Nutzern, die eingebettete Inhalte nutzen: Kunden, die nur auf Daten zugreifen sollten, 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 allen Kunden anzeigen, die Ihr Produkt verwenden. 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 namens products mit einigen Produktmesswerten für verschiedene Marken. Jede Marke entspricht einem anderen eingebetteten Nutzer (mit einer anderen external_user_id) in der signierten Einbettungsanwendung. Da jeder Nutzer, der einbettet, nur die Daten für seine eigene Marke sehen soll, haben Sie in einem Explore einen Zugriffsfilter für das Benutzerattribut Marke verwendet:
explore: products {
access_filter: {
field: products.brand
user_attribute: brand
}
}
Sie haben ein Dashboard, das auf diesem Explore basiert und zwei Kacheln enthält: Auf der einen ist der Name der Marke zu sehen, auf der anderen die Anzahl der Produkte für diese Marke.
Mit dem Endpunkt create_sso_embed_url können Sie Einbettungs-URLs dieses Dashboards für jeden Nutzer generieren.
In diesem Beispiel werden zwei Marken verwendet: Pied Piper und Hooli. Hier ist der Anfragetext, den du in der create_sso_embed_url-Aufruf für Pied Piper verwendest, mit external_user_id pied_piper:
{
"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"}
}
Über die von Ihnen für Pied Piper generierte URL wird das Dashboard so angezeigt:
Hier ist der Anfragetext, der im create_sso_embed_url-Aufruf für Hooli mit external_user_id hooli verwendet wurde:
{
"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"}
}
Über die für Hooli generierte URL wird das Dashboard so angezeigt:
Voilà! Das Dashboard wird nach dem Wert des Nutzerattributs Marke für jeden eingebetteten Nutzer gefiltert.
Mehr erfahren
Sehr cool! Was ist aber, 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 signierte Einbettungsfunktion von Looker wurde entwickelt, um Entwicklern zu ermöglichen, leistungsstarke, maßgeschneiderte Datenfunktionen für Nutzer zu erstellen und gleichzeitig dafür zu sorgen, dass die durch Ihr Datenmodell und Ihre Inhaltszugriffsrichtlinien definierte Datenverwaltung eingehalten wird.
Eine lückenlose Datenverwaltung ist entscheidend, um eine leistungsstarke Datennutzung zu ermöglichen. Im Folgenden finden Sie einige Konzepte und Best Practices, mit denen Sie die für Sie am besten geeignete Umgebung gestalten können. Hier ist ein kurzer Überblick darüber, wie das alles funktioniert.
Grundlagen von signierten Looker-Embeds
Die Nutzerauthentifizierung und -verwaltung in Looker funktioniert im eingebetteten Kontext im Grunde genauso wie im nicht eingebetteten Kontext und im Grunde genauso wie in den meisten anderen Webanwendungen.
Das kann im Kontext von signierten Looker-Embeds verwirrend sein, da der Schritt für die signierte Authentifizierung, die Nutzereinstellungen und das Dashboard selbst in einer langen, komplexen URL kombiniert werden. Diese URL wird jedoch zum Herstellen der Sitzung verwendet. Das gilt auch nach dem Kürzen der URL. Wenn Sie dieses Konzept im Hinterkopf behalten, können Sie viel leichter ansprechende Datenvisualisierungen erstellen.
Struktur der signierten Einbettungs-URL
Hier ist eine der signierten URLs für die Einbettungsauthentifizierung, die durch den create_sso_embed_url-Aufruf mit dem Anfragetext für Pied Piper generiert wurde:
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 ist dieselbe URL decodiert und in einzelne Zeilen unterteilt:
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:
Looker sucht nach einem vorhandenen Nutzerkonto mit
external_user_id= pied_piper. Andernfalls wird in Looker ein neues Nutzerkonto mit dieserexternal_user_iderstellt.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.
Looker authentifiziert den Nutzer und stellt eine Sitzung für ihn her, indem ein Sitzungscookie im Browser gespeichert wird.
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 zu 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 im Grunde dieselben wie bei der Authentifizierung eines regulären Looker-Nutzers, der kein eingebettetes Dashboard verwendet. Angenommen, Sie möchten, dass sich ein Nutzer mit Nutzername und Passwort anmeldet. Der Prozess würde in etwa so aussehen:
Sie (der Looker-Administrator) rufen den Bereich „Verwaltung“ - „Nutzer“ auf und prüfen in der Suchleiste, ob für diesen Nutzer bereits ein Nutzerkonto vorhanden ist. Andernfalls erstellen Sie ein neues Nutzerkonto.
Sie (der Looker-Administrator) klicken im Bereich „Verwaltung“ unter „Nutzer“ neben dem Nutzer auf Bearbeiten und weisen dem Nutzer Berechtigungen, Modelle, Gruppen, Nutzerattributwerte und andere Werte zu.
Der Nutzer ruft die Anmeldeseite unter
https://mylookerinstance.cloud.looker.com/loginauf und gibt seinen Nutzernamen und sein Passwort ein. Looker authentifiziert den Nutzer und stellt eine Sitzung für ihn her, indem ein Sitzungscookie im Browser gespeichert wird.Looker leitet Sie dann zur Landingpage weiter (normalerweise
https://mylookerinstance.cloud.looker.com/browse).
Das Sitzungscookie gilt für jeden Tab im Browserfenster. Wenn der Nutzer auf https://mylookerinstance.cloud.looker.com/browse startet, einen neuen Browsertab öffnet und eine Seite aufruft, auf die er gemäß seinen Berechtigungen Zugriff hat, wird die Seite wie erwartet mit dem Sitzungscookie geladen, das bereits im ursprünglichen Browsertab festgelegt wurde.
Dasselbe gilt für Nutzer, die Inhalte einbetten. Nutzer, die eingebettete Inhalte verwenden, können nur auf Seiten in der Benutzeroberfläche zugreifen, die URLs mit dem Präfix /embed haben. Sie können jedoch weiterhin manuell zu jedem Dashboard wechseln, auf das sie über die Details ihres Nutzerkontos Zugriff haben. Angenommen, die ursprüngliche signierte Embed-URL leitet dich in einem Browsertab zu https://mylookerinstance.cloud.looker.com/embed/dashboards/17 weiter. Öffnen Sie dann einen neuen Browsertab und laden Sie ein anderes eingebettetes Dashboard aus demselben Ordner (mit denselben Zugriffsbeschränkungen) herunter:
https://mylookerinstance.cloud.looker.com/embed/dashboards/19.
Die Weiterleitungs-URL, die in der ursprünglichen signierten Einbettungs-URL angegeben wurde, war für Dashboard 17 bestimmt. Sie sehen jedoch, dass Dashboard 19 wie erwartet geladen wird, wenn Sie die URL manuell in einen Browsertab eingeben. Hinweis: Zum Laden eines anderen Dashboards war keine weitere signierte Embed-URL erforderlich.
Wichtig ist, dass alle in der URL festgelegten Details zum Nutzerkonto (Berechtigungen, Nutzerattribute usw.) auf die gesamte Nutzersitzung angewendet werden, nicht nur auf das Dashboard, das in der ursprünglichen signierten URL angegeben ist. Mit anderen Worten: Nutzerattribute sind, wie der Name schon sagt, eine Funktion des Nutzers, keine Funktion des Dashboards. Sie sollten verwendet werden, um die Zugriffsebenen eines bestimmten Nutzers in der gesamten Anwendung zu bestimmen, nicht nur auf einem bestimmten Tab.
Gleichzeitig auf mehrere Marken zugreifen
Berücksichtigen Sie auch externe Partner, 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 der Perspektive von nicht eingebetteten Inhalten
Nutzersitzungen mit eingebetteter Signatur funktionieren im Grunde genauso wie normale Looker-Nutzersitzungen ohne Einbettung. Daher kann es hilfreich sein, den zuvor beschriebenen problematischen Ansatz im Kontext einer normalen Looker-Nutzersitzung ohne Einbettung neu zu formulieren und die einzelnen Schritte aufzuschlüsseln, um zu verstehen, wie diese Lösung robuster implementiert werden kann. So würde dieser Workflow aussehen, wenn Sie einem Standard-BI-Nutzer mit Zugriff auf die Looker-Benutzeroberfläche eine Anleitung geben:
- Sie erstellen auf der Seite „Verwaltung“ - „Nutzer“ zwei verschiedene Nutzerkonten.
- Auf der Bearbeitungsseite für das erste Nutzerkonto legen Sie den Wert des Nutzerattributs brand auf pied_piper fest.
- Auf der Bearbeitungsseite für das zweite Nutzerkonto legen Sie den Wert des Nutzerattributs Marke auf hooli fest.
- Sie senden E-Mails zur Kontoeinrichtung für beide Nutzerkonten an den Partner.
- Der Partner richtet für jedes Konto separate E-Mail- und Passwort-Anmeldedaten ein.
- Sie geben dem Partner den Link zum Dashboard. (
https://mylookerinstance.cloud.looker.com/dashboards/17), dass er, um das Dashboard zwischen den Marken zu wechseln, auf einem anderen Tab zur Anmeldeseite zurückkehren, die Anmeldedaten für sein anderes Nutzerkonto eingeben und dann das Dashboard auf diesem Tab noch einmal laden muss.
Der Partner folgt der Anleitung. Nachdem er jedoch den Nutzernamen und das Passwort des Hooli-Nutzerkontos im zweiten Browsertab eingegeben und dann zum ersten Tab zurückgekehrt ist, auf dem das Pied Piper-Dashboard bereits geladen war, klickt der Partner auf die Schaltfläche Aktualisieren. Zu seiner Überraschung zeigt das Dashboard die Hooli-Daten an.
Sie fragen sich jetzt vielleicht:
Moment…das ist sehr ärgerlich. Wie gehen Sie am besten vor?
Das ist richtig. Diese Szenarien veranschaulichen ein Prinzip, das im nicht eingebetteten Kontext bereits trivial ist, aber durch die Abstraktion des eingebetteten Kontexts verdeckt werden kann: Ein einzelner Nutzer sollte einem einzelnen Looker-Nutzerkonto mit einem einzelnen Satz von Benutzerattributwerten zugeordnet sein. Das wird auch in unserer Erklärung der external_user_id in der Dokumentation zu signierten Einbettungen deutlich gemacht.
In Looker wird external_user_id verwendet, um angemeldete Nutzer zu unterscheiden. Daher muss jedem Nutzer eine eindeutige ID zugewiesen werden.
Sie können für einen Nutzer einen beliebigen String als external_user_id 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. Die Berechtigungen oder Nutzerattribute eines Nutzers können während einer Sitzung nicht geändert werden.
Was NICHT zu tun ist, wenn Sie gleichzeitig auf mehrere Marken zugreifen
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-Objekte 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:
- Rufen Sie den Tab „Pied Piper“ auf.
- Rufen Sie den Tab „Hooli-Dashboard“ auf.
- Kehren Sie zum Tab „Pied Piper-Dashboard“ zurück.
- Klicke im Pied Piper-Dashboard auf die Schaltfläche Aktualisieren.
…das Pied Piper-Dashboard zeigt die Hooli-Daten an.
Sie können einen ähnlichen Ansatz ausprobieren, aber stattdessen für beide create_sso_embed_url-Aufrufe denselben external_user_id-Nutzer „test_user“ verwenden. Das Verhalten ist jedoch genau das gleiche: Sobald der Tab mit dem Pied Piper-Dashboard neu geladen wird, werden stattdessen 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 der Perspektive von nicht eingebetteten Apps beschriebenen Ansatz anwenden möchten, benötigen Sie einen einzelnen Wert für das Nutzerattribut, der Zugriff auf ALLE Daten gewährt, auf die der Partner in der gesamten Anwendung Zugriff haben soll. Dazu können Sie einen kommagetrennten Wert für das Attribut „Marke“ Pied Piper,Hooli 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,Hooli"}
}
Damit diese Syntax funktioniert, muss Ihr Nutzerattribut als Stringfilter (erweitert) festgelegt sein:
Sie können die Nutzerattribute für einen Nutzer auch dann ändern, wenn sich seine Datenzugriffsebenen ändern. Wenn der Partner beispielsweise die Inhaberschaft an einer dritten Marke übernimmt, können Sie diese dritte Marke der durch Kommas getrennten Liste hinzufügen, die Sie für das Nutzerattribut Marke angegeben haben. So werden die Änderungen übernommen, wenn sich der Nutzer abmeldet und wieder anmeldet.
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 jedoch so angeben, werden die Daten für alle diese Marken in meinem Dashboard angezeigt. Wie kann ich die Ergebnisse eines bestimmten Dashboards auf eine bestimmte Marke eingrenzen?
Die richtige Methode zum Filtern eines bestimmten Dashboards sind die Dashboard-Filter. Das mag jetzt offensichtlich erscheinen, aber einige Nutzer haben sich darauf verlassen, dass Nutzerattribute die einzige Möglichkeit sind, Filter im Einbettungskontext anzuwenden. Das liegt möglicherweise daran, dass user_attributes ein Parameter in der signierten Einbettungs-URL ist und Filter nicht.
Achten Sie darauf, dass ein Filterwert erforderlich ist, und verwenden Sie eine der Steuerelementoptionen für die Einzelauswahl, z. B. ein Drop-down-Menü:
Achten Sie darauf, dass der Filter auf allen erforderlichen Kacheln auf das richtige Feld angewendet wird:
Jetzt kann Ihr Partner zwischen diesen beiden (und nur diesen beiden) Werten auswählen, da die verfügbaren Optionen im Drop-down-Menü durch die Nutzerattribute eingeschränkt sind:
Dashboard-Filter vorab ausfüllen
Okay, jetzt kann das Dashboard 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 im nicht eingebetteten Kontext funktioniert. Wie sende ich jemandem einen Link zu einem Dashboard, für das bereits ein bestimmter Filterwert angewendet wurde? Möglicherweise haben Sie schon bemerkt, dass der ausgewählte Filterwert in der URL für das Dashboard angezeigt wird:
Füge diesen Teil der URL in deinen 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 du das Embed SDK verwendest, kannst du mit withFilters die ersten 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 in ?Brand=Pied+Piper als „+“ codiert ist). Diese Werte werden dann in der finalen URL doppelt codiert. Weitere Informationen finden Sie unter Einbettetes Google Analytics-Dashboard – Dashboard-Filter als Teil der URL festlegen? In diesem Beitrag in der Looker-Community werden diese Nuancen erläutert. Wenn Sie weiterhin Probleme haben, die Filter anzuwenden, können Sie in diesem Communitybeitrag auch Fragen stellen.
Dashboard-Filter ausblenden
Okay, ich weiß jetzt, wie ich die ersten Filter in meinen Dashboards festlege. Ich möchte aber auch nicht, dass der Partner die Dashboard-Filter selbst ändert. Der Filterwert sollte NUR davon abhängen, auf welches Dashboard der Partner in meiner App zugegriffen hat. Wie kann ich die Dashboard-Filter ausblenden?
Sie können dazu Themen verwenden. Themen sind eine kostenpflichtige Funktion. Wenn diese Option in Ihrer Looker-Instanz noch nicht aktiviert ist, wenden Sie sich bitte an Ihr Looker-Vertriebsteam, um sie aktivieren zu lassen.
Nachdem Sie diese Funktion aktiviert haben, rufen Sie auf der Seite „Verwaltung“ unter „Designvorlagen“ den Bereich Dashboard-Steuerelemente auf. Dort können Sie die Option Filterleiste anzeigen deaktivieren:
Sie können das Design dann als Standard festlegen oder es in der URL Ihrer Dashboards anwenden. Auch hier wird der Wert in die target_url 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 eingebetteten Dashboard-Filtern, einschließlich einiger Code-Snippets für das eingebettete 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 das Dashboard jeder Marke immer für die richtige Marke gefiltert angezeigt, auch wenn Sie zwischen den Tabs wechseln.
Als andere Nutzer testen
Jetzt entspricht die User Experience in etwa dem, was ich mir ursprünglich vorgestellt hatte. In meinem Anwendungsfall hat der Partner jedoch andere Berechtigungen und andere Nutzereinstellungen, die die einzelnen Nutzer mit external_user_id=pied_piper und external_user_id=hooli nicht haben. Dies führt zu unterschiedlichen Optionen in der Benutzeroberfläche und insgesamt zu einer etwas anderen Nutzererfahrung. Ich möchte einem Nutzer ermöglichen, alles genau so zu sehen, wie es die Nutzer pied_piper und hooli sehen, als ob sich die Person tatsächlich als diese Nutzer angemeldet hätte. Wie kann ich das tun?
Wenn ein Nutzer als jeder einzelne Markennutzer testen soll, können Sie in Ihrer App eine ähnliche Sudo-Funktion erstellen, die die Einbettungs-URLs für external_user_id=pied_piper lädt, wenn der Nutzer als Pied Piper-Nutzer Sudo verwendet, und die Einbettungs-URLs für external_user_id=hooli, wenn der Nutzer als Hooli-Nutzer Sudo verwendet. Du kannst auch den login_user API-Endpunkt verwenden, um als Markennutzer mit der API „sudo“ auszuführen, wenn deine App die API nutzt.
Denken Sie jedoch noch einmal an den nicht eingebetteten Kontext: Auf der Seite „Verwaltung“ - „Nutzer“ können Sie nicht gleichzeitig als mehrere nicht eingebettete Nutzer auf mehreren Tabs „sudo“ ausführen. Die „sudo“-Sitzung gilt wie alle anderen Nutzersitzungen für das gesamte Browserfenster. Daher sollten Sie „sudo“ so konfigurieren, dass immer nur ein Nutzer gleichzeitig „sudo“ ausführen kann. Und wenn Sie darüber nachdenken, ist dieses Design konsistenter, da es die Nutzung durch die Nutzer, als die Sie „sudo“ verwenden, 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 „sudo“ verwenden.
Fazit
Wir hoffen, dass dieser Leitfaden hilfreich war und dass Sie nun gut gerüstet sind, um Ihre eingebetteten Looker-Inhalte zu erstellen. Wir arbeiten ständig daran, Looker zum flexibelsten und robustesten eingebetteten Analysetool für Daten zu machen. Wir 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.