Notez que vous consultez actuellement la documentation de Looker. Pour accéder à la documentation sur Looker Studio, consultez la page https://support.google.com/looker-studio.

Cette page a été traduite par l'API Cloud Translation.

Implémentation de la segmentation au niveau des lignes pour le contenu Looker intégré

Auteur : Christopher Seymour, analyste de données senior, et Dean Hicks, ingénieur chargé des relations avec les développeurs

La segmentation au niveau des lignes vous permet de limiter les données auxquelles un utilisateur individuel peut accéder, en fonction des valeurs stockées dans un ou plusieurs champs de base de données. Ce guide décrit les méthodes d'implémentation de la segmentation au niveau des lignes dans le contenu Looker intégré et contient les sections suivantes:

Présentation
- Présentation du cas d'utilisation
- Approfondir l'analyse
Principes de base de l'intégration signée Looker
- Structure de l'URL d'intégration signée
Accéder à plusieurs marques en même temps
- L'approche hors intégration
- Accéder à plusieurs marques en même temps : ce qu'il ne faut PAS faire
Appliquer ces bonnes pratiques
Conclusion

Présentation

La fonctionnalité d'intégration de Looker est l'une des fonctionnalités les plus puissantes et les plus utiles du produit Looker. Si vous lisez ce guide, vous êtes probablement en train d'intégrer du contenu Looker dans votre application, ou vous avez probablement l'intention de le faire prochainement.

L'objectif de ce guide est de vous aider à mieux comprendre la conception de la fonctionnalité d'intégration de Looker et à vous aider à implémenter la segmentation dans une application permettant aux partenaires de gérer l'accès à plusieurs marques. Il est un peu long à lire ce sujet en détail. N'oubliez pas que ce guide n'est pas destiné à résoudre rapidement un problème simple, mais plutôt à vous aider à mieux gérer l'ensemble de votre cas d'utilisation des intégrations Looker.

Présentation du cas d'utilisation

Ce guide décrit un cas d'utilisation courant où votre entreprise intègre du contenu Looker à son produit et dessert des segments d'utilisateurs qui doivent voir différents segments de vos données.

Pour ce cas d'utilisation d'intégration signée, supposons que vous êtes l'administrateur de votre instance Looker. Vous travaillez avec deux types d'utilisateurs externes intégrés: les clients, qui ne doivent pouvoir accéder qu'aux données relatives à leur marque spécifique, et les partenaires, qui peuvent accéder aux données de plusieurs marques. Vous disposez d'un tableau de bord avec quelques vignettes que vous présentez à chaque client qui utilise votre produit, mais vous avez besoin que le tableau de bord soit automatiquement filtré pour chaque client afin que les tableaux de bord n'affichent que les données qui sont spécifiques à ce client. Les exemples de ce document font appel à deux entreprises fictives : Hooli et Joueur de flics.

Vous avez un tableau appelé produits, qui affiche des métriques de produits pour différentes marques. Chaque marque correspond à un utilisateur intégré différent (avec un external_user_id différent) dans l'application d'intégration signée. Étant donné que chaque utilisateur de l'intégration ne doit voir que les données relatives à sa propre marque, une exploration utilise un filtre d'accès basé sur un attribut utilisateur brand:

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

Vous disposez d'un tableau de bord basé sur cette exploration et comportant deux vignettes: l'une affiche le nom de la marque et l'autre le nombre de produits de cette marque.

Le point de terminaison create_sso_embed_url permet de générer les URL d'intégration de ce tableau de bord pour chaque utilisateur intégré. Cet exemple utilise deux marques: Pied de jambe et Hooli. Voici le corps de la requête que vous utilisez dans l'appel create_sso_embed_url pour le joueur de pied, avec 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"}
}

L'URL que vous avez générée pour le joueur de pied affiche le tableau de bord comme suit:

Voici le corps de la requête utilisé dans l'appel create_sso_embed_url pour Hooli, avec 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"}
}

L'URL générée pour Hooli affiche le tableau de bord comme suit:

C'est terminé ! Le tableau de bord est filtré en fonction de la valeur de l'attribut utilisateur brand (marque) de chaque utilisateur intégré.

En savoir plus

Très cool ! Mais que se passe-t-il si je veux autoriser un seul utilisateur à accéder à plusieurs marques ? Comment puis-je m'assurer que mes données ne sont visibles que par les utilisateurs pertinents ?

Bonne nouvelle ! La fonctionnalité d'intégration signée de Looker a été conçue pour permettre aux développeurs de créer des expériences de données puissantes et personnalisées pour les utilisateurs tout en garantissant le maintien de la gouvernance des données définie par votre modèle de données et vos règles d'accès au contenu.

Il est essentiel de s'assurer que la gouvernance des données est parfaite pour fournir cette expérience de données efficace. Poursuivez votre lecture pour découvrir certains concepts et bonnes pratiques que vous pouvez utiliser pour concevoir l'expérience qui vous convient le mieux. Tout d'abord, nous allons voir comment tout cela fonctionne.

Principes de base de l'intégration signée Looker

Il est important de garder à l'esprit que l'authentification et la gestion des utilisateurs de Looker dans le contexte d'incorporation fonctionnent fondamentalement de la même manière que dans le contexte sans intégration et fondamentalement de la même manière que la plupart des autres applications Web.

Cela peut prêter à confusion dans le contexte d'incorporation signée de Looker, car l'étape d'authentification signée, les paramètres utilisateur et le tableau de bord lui-même sont tous combinés en une seule URL longue et complexe. Cependant, cette URL est utilisée pour établir la session, qui s'applique toujours même après que l'URL a été raccourcie. Garder ce concept à l'esprit contribuera grandement à votre succès dans la création d'expériences de données de qualité.

Structure de l'URL d'intégration signée

Voici l'une des URL d'authentification d'intégration signée générée par l'appel create_sso_embed_url avec le corps de la requête pour Pied de Piper:

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

Voici la même URL décodée et divisée en lignes distinctes:

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

Lorsque vous accédez à cette URL, voici ce qui se produit:

Looker recherche un compte utilisateur existant dont le paramètre external_user_id est pied_piper. S'il n'en existe aucun, Looker crée un compte utilisateur avec ce external_user_id.
Les détails du compte de l'utilisateur existant, y compris les autorisations, les modèles, les groupes (le cas échéant) et les valeurs des attributs utilisateur (le cas échéant), sont remplacés par les détails du compte spécifiés dans l'URL.
Looker authentifie l'utilisateur et établit une session pour cet utilisateur en stockant un cookie de session dans le navigateur.
Looker redirige ensuite vers l'URL cible, ou URL de redirection, spécifiée dans l'appel create_sso_embed_url:

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

Vous pouvez voir cette URL de redirection en tant qu'URL relative encodée dans l'URL d'intégration signée d'origine:

%2Fembed%2Fdashboards%2F17

Bien que les étapes 1 à 3 se produisent automatiquement en arrière-plan et que tout ce que l'utilisateur final voit soit le résultat final (le tableau de bord lui-même), ces étapes sont fondamentalement les mêmes que celles avec lesquelles un utilisateur Looker standard sans intégration s'authentifie. Supposons que vous souhaitiez qu'un utilisateur se connecte avec des identifiants d'utilisateur et de mot de passe. Le processus ressemblerait à ceci:

Vous (l'administrateur Looker) accédez au panneau Admin - Users et utilisez la barre de recherche pour vérifier si un compte utilisateur existe déjà pour cet utilisateur. Si ce n'est pas le cas, vous devez créer un autre compte utilisateur.
Vous (l'administrateur Looker) cliquez sur Modifier à côté de l'utilisateur dans le panneau Admin > Utilisateurs et provisionnez cet utilisateur avec des autorisations, des modèles, des groupes, des valeurs d'attributs utilisateur, etc.
L'utilisateur accède à la page de connexion à l'adresse https://mylookerinstance.cloud.looker.com/login, puis saisit son nom d'utilisateur et son mot de passe. Looker authentifie l'utilisateur et établit une session pour cet utilisateur en stockant un cookie de session dans le navigateur.
Looker redirige ensuite vers la page de destination (généralement https://mylookerinstance.cloud.looker.com/browse).

Notez que le cookie de session s'appliquera à chaque onglet de la fenêtre du navigateur. Si l'utilisateur démarre le https://mylookerinstance.cloud.looker.com/browse, ouvre un nouvel onglet de navigateur et accède à une page à laquelle ses autorisations lui donnent accès, la page se chargera comme prévu avec le cookie de session déjà établi dans l'onglet d'origine du navigateur.

Il en va de même pour les utilisateurs intégrés. Les utilisateurs intégrés sont un peu plus limités quant aux pages auxquelles ils peuvent accéder dans l'interface utilisateur : seules les URL de présentation, de tableau de bord et d'exploration comportant le préfixe /embed sont autorisées. Ils peuvent toutefois accéder manuellement à n'importe quel tableau de bord auquel les informations de leur compte utilisateur leur donnent accès. Supposons que l'URL d'intégration signée d'origine vous redirige vers https://mylookerinstance.cloud.looker.com/embed/dashboards/17 dans un onglet du navigateur. Vous ouvrez ensuite un nouvel onglet de navigateur et chargez un autre tableau de bord d'intégration qui se trouve dans le même dossier (et présente donc les mêmes restrictions d'accès) : https://mylookerinstance.cloud.looker.com/embed/dashboards/19.

Bien que l'URL de redirection spécifiée dans l'URL d'ingestion signée d'origine soit associée au tableau de bord 17, vous pouvez constater que le tableau de bord 19 se charge comme prévu si vous saisissez manuellement l'URL dans un onglet du navigateur. Notez qu'une autre URL d'intégration signée n'était pas nécessaire pour charger un autre tableau de bord.

L'insight clé ici est que tous les détails de compte utilisateur établis dans l'URL (autorisations, attributs utilisateur, etc.) sont appliqués à l'ensemble de la session utilisateur, et pas seulement au tableau de bord spécifique spécifié dans l'URL signée d'origine. En d'autres termes, comme leur nom l'indique, les attributs utilisateur sont une caractéristique de l'utilisateur, et non une fonctionnalité du tableau de bord. Ils doivent être utilisés pour déterminer les niveaux d'accès d'un utilisateur spécifique sur l'ensemble de l'application, et pas seulement dans un onglet spécifique.

Accéder à plusieurs marques en même temps

N'oubliez pas que vous avez également des partenaires externes qui peuvent posséder ou gérer plusieurs marques. Dans cet exemple, un partenaire gère à la fois les marques Piedper et Hooli.

L'approche du point de vue de la non-intégration

Les sessions utilisateur avec incorporation signées fonctionnent fondamentalement de la même manière que les sessions utilisateur Looker classiques sans intégration. Il peut donc être utile de recadrer l'approche problématique décrite précédemment dans le contexte d'une session utilisateur Looker standard sans intégration et de décomposer ces étapes pour comprendre comment mettre en œuvre cette solution de manière plus robuste. Voici à quoi ressemblerait ce workflow si vous fournissiez des instructions à un utilisateur standard de BI qui a accès à l'UI Looker:

Vous créez deux comptes d'utilisateurs différents sur la page Admin - Utilisateurs.
1. Sur la page de modification du premier compte utilisateur, définissez la valeur de l'attribut utilisateur brand sur pied_piper.
2. Sur la page de modification du deuxième compte utilisateur, définissez la valeur de l'attribut utilisateur brand sur hooli.
Vous envoyez des e-mails de configuration des comptes pour les deux comptes utilisateur au partenaire.
Le partenaire configure une adresse e-mail et un mot de passe distincts pour chaque compte.
Vous fournissez au partenaire le lien vers le tableau de bord. (https://mylookerinstance.cloud.looker.com/dashboards/17) et indiquez-lui que, pour changer de marque de tableau de bord, il devra retourner à la page de connexion dans un autre onglet et saisir l'adresse e-mail et le mot de passe de son autre compte utilisateur, puis charger à nouveau le tableau de bord dans cet onglet.

Le partenaire suit les instructions. Toutefois, après avoir saisi le nom d'utilisateur et le mot de passe du compte utilisateur Hooli dans le deuxième onglet du navigateur, puis accédé au premier onglet dans lequel le tableau de bord Pied de jambe était déjà chargé, le partenaire clique sur le bouton Reload (Actualiser). À la surprise du partenaire, le tableau de bord affiche les données Hooli.

Vous vous demandez peut-être maintenant:

Attendez... C'est très gênant. Quelle est la meilleure façon de procéder ?

Absolument ! Ces scénarios permettent d'illustrer un principe qui est déjà anodin dans le contexte hors intégration, mais qui peut être dissimulé par les abstractions du contexte d'intégration: Un seul utilisateur humain doit être associé à un seul compte utilisateur Looker avec un seul ensemble de valeurs d'attributs utilisateur. Cela est également précisé dans notre explication de external_user_id dans notre documentation sur les représentations vectorielles continues signées.

Looker utilise external_user_id pour différencier les utilisateurs d'intégrations signées. Un ID unique doit donc être attribué à chaque utilisateur.

Vous pouvez créer un external_user_id pour un utilisateur avec n'importe quelle chaîne, à condition qu'elle soit propre à cet utilisateur. Chaque ID est associé à un ensemble d'autorisations, d'attributs utilisateur et de modèles. Un seul navigateur ne peut prendre en charge qu'une seule external_user_id, ou session utilisateur, à la fois. Aucune modification ne peut être apportée aux autorisations ou aux attributs d'un utilisateur en cours de session.

Accéder à plusieurs marques en même temps : ce qu'il ne faut PAS faire

Comme pour toute solution personnalisable, vous devez éviter certaines approches. Par exemple, une implémentation dans laquelle votre application génère les URL des deux external_user_ids à l'aide des mêmes entrées de l'appel create_sso_embed_url que précédemment, et crée un onglet dans l'application pour charger chaque tableau de bord auquel le partenaire doit accéder. Nous avons souvent vu des développeurs implémenter des solutions de ce type, ce qui entraîne un workflow incorrect pour l'utilisateur:

Accédez à l'onglet du tableau de bord de Pied de jambe.
Accédez à l'onglet du tableau de bord Hooli.
Revenez à l'onglet du tableau de bord de Pied de fléchette.
Cliquez sur le bouton Actualiser du tableau de bord du Joueur de jambes.

...le tableau de bord Piedper affiche les données Hooli.

Vous pouvez essayer une approche similaire, mais utiliser le même external_user_id test_user pour les deux appels create_sso_embed_url. Mais le comportement est exactement le même : une fois que l'onglet est rechargé avec le tableau de bord de Joueur de pied, les données de Hooli s'affichent à la place.

Comment puis-je m'assurer que le tableau de bord d'une marque n'affiche que les données la concernant ?

Mettre en pratique les bonnes pratiques

Pour appliquer l'approche décrite dans la section Approche sans intégration, vous avez besoin d'une seule valeur d'attribut utilisateur accordant l'accès à TOUTES les données auxquelles le partenaire doit avoir accès dans l'application. Pour ce faire, spécifiez une valeur séparée par une virgule pour l'attribut brand 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"}
}

Pour que cette syntaxe fonctionne, vous devez vous assurer que votre attribut utilisateur est défini sur Filtre de chaîne (avancé):

Notez que vous pouvez toujours modifier l'ensemble d'attributs utilisateur d'un utilisateur si quelque chose change dans ses niveaux d'accès aux données. Par exemple, si le partenaire acquiert la propriété d'une troisième marque, vous pouvez ajouter cette dernière à la liste d'éléments séparés par une virgule que vous avez spécifiée pour son attribut utilisateur brand. Ainsi, lorsqu'ils se déconnectent et se reconnectent, les modifications sont appliquées.

Filtrer les résultats du tableau de bord

D'accord, les attributs utilisateur doivent spécifier toutes les données auxquelles l'utilisateur peut accéder dans l'application. Mais si je spécifie les attributs utilisateur de cette façon, les données de toutes ces marques s'afficheront dans mon tableau de bord. Comment limiter les résultats d'un tableau de bord à une marque spécifique ?

La bonne façon de filtrer un tableau de bord particulier consiste à utiliser d'anciens filtres. (Cela peut sembler évident, mais nous avons constaté que certaines personnes se bloquaient sur les attributs utilisateur comme seul moyen d'appliquer des filtres dans le contexte de l'intégration, peut-être parce que user_attributes est un paramètre de l'URL d'intégration signée, alors que les filtres ne l'est pas.)

Assurez-vous d'exiger une valeur de filtre et d'utiliser l'une des options de la commande de sélection unique, comme le menu déroulant:

Assurez-vous que le filtre est appliqué au champ approprié sur toutes les vignettes nécessaires:

Votre partenaire peut désormais choisir entre ces deux valeurs (et seulement ces deux), car les options disponibles dans le menu déroulant sont limitées par les attributs utilisateur:

Préremplir les filtres du tableau de bord

D'accord. Vous pouvez désormais filtrer le tableau de bord par marque spécifique, mais j'aimerais que la valeur du filtre soit déjà définie sur une marque spécifique lorsque l'utilisateur charge le tableau de bord de cette marque dans mon application.

Encore une fois, il est utile de réfléchir à la façon dont cela fonctionne dans le contexte sans intégration. Comment envoyer à quelqu'un un lien vers un tableau de bord auquel une valeur de filtre spécifique est déjà appliquée ? Vous avez peut-être remarqué que lorsque vous sélectionnez une valeur de filtre, cette valeur apparaît dans l'URL du tableau de bord:

Incluez cette partie de l'URL dans votre target_url pour l'appel create_sso_embed_url:

{
  "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"}
}

Si vous utilisez le SDK d'intégration, vous pouvez utiliser withFilters pour spécifier les filtres initiaux à appliquer au contenu intégré:

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

Si vous utilisez votre propre script personnalisé, pensez à ajouter le filtre à l'URL avant d'encoder le chemin. Il est possible que certaines valeurs soient déjà encodées dans la chaîne de filtre (par exemple, un espace est encodé sous la forme + dans ?Brand=Pied+Piper). Ces valeurs seront donc encodées deux fois dans l'URL finale. Nous vous invitons à consulter la page SI Embedded Dashboard - set dashboard filter as part of URL? Post destiné à la communauté Looker pour discuter de ces nuances. Si le problème persiste, n'hésitez pas à poser vos questions dans un post destiné à la communauté.

Masquage des filtres du tableau de bord

Je vois comment définir les filtres initiaux dans mes tableaux de bord, mais je ne veux pas non plus que le partenaire modifie lui-même les filtres du tableau de bord. La valeur du filtre doit être déterminée UNIQUEMENT en fonction du tableau de bord auquel il a accédé dans mon application. Comment puis-je masquer les filtres des tableaux de bord ?

Pour ce faire, vous pouvez utiliser des thèmes. Les thèmes sont une fonctionnalité payante. Si vous ne l'avez pas déjà activé sur votre instance Looker, vous devez contacter votre équipe commerciale Looker pour l'activer.

Une fois cette fonctionnalité activée, accédez à la section Commandes du tableau de bord de la page "Admin - Thèmes", puis décochez l'option Afficher la barre de filtres:

Vous pouvez ensuite définir votre thème comme thème par défaut ou l'appliquer dans l'URL de vos tableaux de bord spécifiques. Là encore, le target_url de l'appel create_sso_embed_url est placé:

{
  "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"}
}

Pour en savoir plus sur le masquage des filtres d'intégration des tableaux de bord, y compris sur certains extraits de code du SDK d'intégration, consultez ce tutoriel YouTube intitulé Intégrer Looker à des filtres personnalisés.

Le résultat final doit ressembler à l'expérience utilisateur de la question initiale:

Toutefois, comme les valeurs des filtres sont encodées dans les URL cibles respectives intégrées à l'application, le tableau de bord de chaque marque affichera toujours le tableau de bord filtré sur la marque appropriée, même lorsque vous passerez d'un onglet à l'autre.

Tester comme les autres utilisateurs

L'expérience utilisateur ressemble maintenant à celle que j'avais imaginée au départ. Toutefois, dans mon cas d'utilisation, le partenaire dispose d'autorisations et d'autres paramètres utilisateur différents que les utilisateurs individuels de external_user_id=pied_piper et external_user_id=hooli n'ont pas. Les options disponibles dans l'UI sont donc différentes, mais l'expérience utilisateur globale est légèrement différente. Je souhaite permettre à un utilisateur de voir toutes les informations telles que les utilisateurs pied_piper et pied_piper les voient, comme si l'utilisateur s'était connecté sous ce nom. Comment procéder ?

Si vous souhaitez qu'un utilisateur puisse effectuer des tests en tant qu'utilisateur individuel de la marque, vous pouvez créer une fonction sudo similaire dans votre application, qui chargera les URL d'intégration pour external_user_id=pied_piper lorsque l'utilisateur effectue une commande sudo en tant qu'utilisateur Pied de jambe et les URL d'intégration pour external_user_id=hooli lorsqu'il effectue une action sudo en tant qu'utilisateur Hooli. Vous pouvez également utiliser le point de terminaison de l'API login_user pour effectuer une commande sudo en tant qu'utilisateur de marque avec l'API si votre application l'utilise.

Cependant, si vous pensez à nouveau au contexte de non-intégration: sur la page Admin - Users, vous ne pouvez pas utiliser simultanément la commande sudo pour plusieurs utilisateurs non intégrés dans plusieurs onglets. La session sudo s'appliquera à l'ensemble de la fenêtre du navigateur, comme toutes les autres sessions utilisateur. Vous devez donc définir la commande "sudo" sur "sudo" comme un seul utilisateur à la fois. Et, si vous y réfléchissez, cette conception est plus cohérente avec l'imitation parfaitement de l'expérience des utilisateurs sous lesquels vous utilisez la commande sudo. Par exemple, l'utilisateur pied_piper peut uniquement accéder au tableau de bord de Joueur de jambes et n'a pas la possibilité d'ouvrir d'autres tableaux de bord dans d'autres onglets. Par conséquent, vous ne devriez pas non plus pouvoir ouvrir différents tableaux de bord dans différents onglets lorsque vous utilisez une commande Sudo en tant qu'utilisateur.

Conclusion

Nous espérons que ce guide vous a été utile et que vous êtes prêt à créer votre contenu intégré avec signature Looker ! Nous nous efforçons constamment de faire de Looker la solution d'analyse de données intégrée la plus flexible et la plus robuste, et nous aimerions connaître votre avis ! Si vous avez des questions ou souhaitez en savoir plus, vous pouvez vous adresser à la communauté Looker et participer à nos événements de la communauté.