Beachten Sie, dass Sie sich die Looker-Dokumentation ansehen. Dokumentation zu Looker Studio finden Sie unter https://support.google.com/looker-studio.

Diese Seite wurde von der Cloud Translation API übersetzt.

Segmentierung auf Zeilenebene für eingebettete Looker-Inhalte implementieren

Autor: 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, und zwar basierend auf den Werten, die in einem oder mehreren Datenbankfeldern gespeichert sind. In diesem Leitfaden werden Methoden zum Implementieren der Segmentierung auf Zeilenebene in eingebetteten Looker-Inhalten beschrieben. Er enthält die folgenden Abschnitte:

Einführung
- Anwendungsfallübersicht
- Mehr Möglichkeiten
Grundlagen der signierten Einbettung von Looker
- Struktur der signierte Einbettungs-URL
Gleichzeitig auf mehrere Marken zugreifen
- Der Ansatz ohne Einbettung
- Zugriff auf mehrere Marken gleichzeitig – was du NICHT tun solltest
Diese Best Practices
Fazit

Einleitung

Die Einbettungsfunktionen von Looker sind 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 und die Segmentierung für eine Anwendung zu implementieren, in der Partner den Zugriff auf mehrere Marken verwalten können. 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 und Segmente von Nutzern bedient, die unterschiedliche Segmente Ihrer Daten sehen sollten.

Gehen Sie für diesen Anwendungsfall für signierte Einbettungen davon aus, dass Sie der Administrator Ihrer Looker-Instanz sind. Sie arbeiten mit zwei Arten von externen eingebetteten Nutzern zusammen: Kunden, die nur auf Daten zugreifen dürfen, die sich auf ihre spezifische Marke beziehen, und Partner, die auf die Daten mehrerer Marken 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 Explore, das einen Zugriffsfilter für ein Nutzerattribut vom Typ brand verwendet:

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

Sie haben ein 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! Aber 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 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:

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.
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).
Looker authentifiziert den Nutzer und richtet eine Sitzung für diesen Nutzer ein, indem ein Sitzungscookie im Browser gespeichert wird.
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:

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.
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.
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.
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.

Gleichzeitig auf mehrere Marken zugreifen

Möglicherweise hast du auch externe Partner, die mehrere Marken besitzen oder verwalten. In diesem Beispiel verwaltet ein Partner sowohl die Marken Rattenfänger als auch die Marken Hooli.

Der Ansatz aus der Perspektive von Nicht-Einbettungen

Benutzersitzungen mit signierten Einbettungen funktionieren 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:

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.
Sie senden E-Mails zur Kontoeinrichtung für beide Nutzerkonten an den Partner.
Der Partner richtet für jedes Konto eine eigene E-Mail-Adresse und ein eigenes Passwort ein.
Sie stellen dem Partner den Link zum Dashboard zur Verfügung. (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 Partner 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 Dashboard mit dem Rattenfänger bereits geladen war, klickt der Partner auf die Schaltfläche Aktualisieren. Zur Überraschung des Partners werden im Dashboard die Hooli-Daten angezeigt.

Sie denken jetzt vielleicht:

Moment ... das ist sehr lästig. Wie gehen Sie dann am besten vor?

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.

Der gleichzeitige Zugriff auf mehrere Marken – was du NICHT tun solltest

Wie bei jeder anpassbaren Lösung gibt es auch hier bestimmte Ansätze, die Sie vermeiden sollten. Beispiel: Eine Implementierung, bei der deine App die URLs für beide external_user_ids mit denselben Eingaben im zuvor gezeigten create_sso_embed_url-Aufruf generiert und einen neuen Tab in der App erstellt, um jedes Dashboard zu laden, auf das der Partner zugreifen muss. Häufig haben Entwickler Lösungen wie diese implementiert, was zu einem falschen Workflow für Nutzer führt:

Navigieren Sie zum Dashboard-Tab im Rattenfänger.
Gehen Sie zum Tab „Hooli“-Dashboard.
Gehe zurück zum Dashboard-Tab im Rattenfänger.
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, verwenden jedoch stattdessen denselben external_user_id test_user für beide create_sso_embed_url-Aufrufe. Das Verhalten ist jedoch dasselbe: Sobald der Tab mit dem Dashboard mit dem Rattenfänger neu geladen wurde, werden stattdessen die Daten für Hooli angezeigt.

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

Best Practices anwenden

Wenn Sie den im Abschnitt Der Ansatz ohne Einbettung beschriebenen Ansatz anwenden möchten, benötigen Sie einen einzelnen Nutzerattributwert, der Zugriff auf ALLE Daten gewährt, auf die der Partner 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 der Partner beispielsweise 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 Ihr Partner 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 Partner die Dashboard-Filter selbst ändert – der Filterwert sollte NUR dadurch bestimmt werden, welches Dashboard der Partner 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.

Im Namen anderer Nutzer testen

Jetzt entspricht die Nutzererfahrung sehr stark dem, was ich ursprünglich gedacht 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. Das führt zu anderen verfügbaren Optionen in der Benutzeroberfläche und zu einer etwas anderen Nutzererfahrung. Ich möchte Nutzern ermöglichen, alles genau so zu sehen, wie dies pied_piper und pied_piper die Nutzer sehen, so als ob die Person sich tatsächlich als diese Nutzer angemeldet hätte. Wie kann ich das erreichen?

Wenn Sie möchten, dass ein Nutzer als jeder einzelne Markennutzer testen kann, können Sie eine ähnliche sudo-Funktion in Ihrer App erstellen, die die eingebetteten URLs für external_user_id=pied_piper lädt, wenn der Nutzer als Pied Piper-Nutzer im SUDO-Status sudo-Befehl, und die Einbettungs-URLs für external_user_id=hooli, wenn der Nutzer als Hooli-Nutzer Sudo verwendet. 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.