Notez que vous consultez la documentation 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émenter une segmentation au niveau des lignes pour le contenu Looker intégré

Auteurs : Christopher Seymour, Sr. Data Analyst, et Dean Hicks, Developer Relations Engineer

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 permettant d'implémenter 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
Principes de base de l'intégration avec signature Looker
- Structure de l'URL d'intégration signée
Accéder simultanément à plusieurs marques
- Approche non intégrée
- Accéder à plusieurs marques à la fois : 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, il est probable que vous intégriez déjà du contenu Looker dans votre application ou que vous prévoyez 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 comment implémenter la segmentation dans une application dans laquelle les partenaires peuvent gérer l'accès à plusieurs marques. Comme il s'agit d'un examen approfondi du sujet, la lecture est un peu longue. Gardez à l'esprit que ce guide n'a pas vocation à résoudre rapidement un problème simple, mais plutôt à vous aider à mieux gérer l'ensemble de votre cas d'utilisation de l'intégration Looker.

Présentation du cas d'utilisation

Ce guide décrit un cas d'utilisation courant dans lequel votre entreprise intègre du contenu Looker à votre 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 concernant leur marque spécifique, et les partenaires, qui pourront 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 devez filtrer automatiquement le tableau de bord pour chaque client afin que les tableaux de bord n'affichent que les données spécifiques à ce client. Les exemples de ce document utilisent deux entreprises fictives : Hooli et Pied Piper.

Le tableau products contient des métriques sur les produits pour différentes marques. Chaque marque correspond à un utilisateur d'intégration différent (avec un external_user_id différent) dans l'application d'intégration signée. Étant donné que chaque utilisateur intégré ne doit pouvoir consulter que les données de sa propre marque, vous disposez d'une exploration qui utilise un filtre d'accès sur un attribut utilisateur marque:

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

Vous avez un tableau de bord basé sur cette exploration et qui comporte deux vignettes: l'une indique le nom de la marque et l'autre le nombre de produits de cette marque.

Vous utilisez le point de terminaison create_sso_embed_url pour générer les URL d'intégration de ce tableau de bord pour chaque utilisateur d'intégration. Cet exemple utilise deux marques: Pied de Piper et Hooli. Voici le corps de requête que vous utilisez dans l'appel create_sso_embed_url pour Pied Piper, 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 Pied Piper affiche le tableau de bord de la manière suivante:

Voici le corps de requête utilisé dans l'appel create_sso_embed_url pour Hooli, avec des hooli external_user_id:

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

Voilà Le tableau de bord est filtré en fonction de la valeur de chaque utilisateur intégré pour l'attribut utilisateur brand.

Pour aller plus loin

Super ! Mais que se passe-t-il si je souhaite accorder à un seul utilisateur l'accès à plusieurs marques ? Comment m'assurer que mes données ne sont visibles que par les utilisateurs concernés ?

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 veillant à ce que la gouvernance des données définie par votre modèle de données et vos règles d'accès au contenu soit maintenue.

Pour offrir une expérience de données efficace, il est essentiel de s'assurer que la gouvernance des données est rigoureuse. Poursuivez votre lecture pour découvrir quelques concepts et bonnes pratiques à suivre pour concevoir l'expérience qui vous convient le mieux. Voici un bref aperçu du fonctionnement de tout cela.

Principes de base de l'intégration avec signature Looker

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

Cela peut être déroutant dans le contexte d'incorporation signée Looker, car l'étape d'authentification signée, les paramètres utilisateur et le tableau de bord lui-même sont combinés en une seule URL longue et complexe. Cependant, cette URL permet d'établir la session, ce qui s'applique même une fois l'URL 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 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 individuelles:

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, plusieurs choses se produisent :

Looker recherche un compte utilisateur existant avec external_user_id = pied_piper. S'il n'en existe aucun, Looker crée un compte utilisateur avec ce external_user_id.
Les informations de 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 écrasées par les informations de compte spécifiées 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 l'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 sous la forme d'une 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 l'utilisateur final ne voit que le résultat final (le tableau de bord lui-même), ces étapes sont fondamentalement les mêmes que celles qu'un utilisateur Looker standard non intégré s'authentifie. Supposons que vous souhaitiez qu'un utilisateur se connecte avec des identifiants utilisateur et un mot de passe. Le processus ressemblerait à ceci:

Vous (l'administrateur Looker) accédez au panneau "Admin - Utilisateurs" 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 nouveau compte utilisateur.
Vous (l'administrateur Looker) cliquez sur Modifier à côté de l'utilisateur dans le panneau "Admin - Utilisateurs", puis vous lui attribuez des autorisations, des modèles, des groupes, des valeurs d'attributs utilisateur et d'autres valeurs.
L'utilisateur accède à la page de connexion à l'adresse https://mylookerinstance.cloud.looker.com/login et 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 navigateur 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 charge comme prévu à l'aide du cookie de session déjà établi dans l'onglet d'origine du navigateur.

Il en va de même pour les utilisateurs d'intégration. Les utilisateurs Embed sont un peu plus limités aux pages auxquelles ils peuvent accéder dans l'interface utilisateur : ils ne peuvent accéder qu'aux URL de présentation, de tableau de bord et d'exploration comportant le préfixe /embed. Toutefois, ils peuvent toujours accéder manuellement à tous les tableaux de bord auxquels les détails 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 situé dans le même dossier (et qui 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'intégration signée d'origine concernait le tableau de bord 17, vous pouvez constater qu'il se charge comme prévu si vous saisissez manuellement l'URL dans un onglet du navigateur. Notez qu'aucune autre URL d'intégration signée n'était nécessaire pour charger un autre tableau de bord.

L'information clé ici est que tous les détails du 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 fonctionnalité de l'utilisateur, et non du tableau de bord. Ils doivent être utilisés pour déterminer les niveaux d'accès d'un utilisateur spécifique dans l'ensemble de l'application, et non uniquement 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 Pied Piper et Hooli.

Approche du point de vue de l'intégration

Les sessions utilisateur intégrées signées fonctionnent fondamentalement de la même manière que les sessions utilisateur Looker standards non intégrées. 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 non intégrée et de décomposer ces étapes pour comprendre comment implémenter cette solution de manière plus robuste. Voici ce à quoi ressemblerait ce workflow si vous donniez des instructions à un utilisateur d'informatique décisionnelle standard ayant accès à l'interface utilisateur de Looker:

Vous pouvez créer deux comptes utilisateur différents sur la page Admin - Utilisateurs.
1. Sur la page de modification du premier compte utilisateur, vous définissez la valeur de l'attribut utilisateur marque sur pied_piper.
2. Sur la page de modification du deuxième compte utilisateur, définissez la valeur de l'attribut utilisateur marque sur hooli.
Vous envoyez des e-mails de configuration des deux comptes utilisateur au partenaire.
Le partenaire définit 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 lui indiquez que, pour changer de marque dans le tableau de bord, il doit revenir à la page de connexion dans un autre onglet, 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 revenir au premier onglet où le tableau de bord Pied Piper était déjà chargé, le partenaire clique sur le bouton Actualiser. À la surprise du partenaire, le tableau de bord affiche les données Hooli.

À présent, vous vous demandez peut-être:

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

Bien sûr ! Ces scénarios permettent d'illustrer un principe déjà trivial dans le contexte non intégré, mais qui peut être obscurci 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 clair dans notre explication de la external_user_id dans notre documentation sur l'intégration signée.

Looker utilise external_user_id pour différencier les utilisateurs intégrés connectés. Par conséquent, chaque utilisateur doit se voir attribuer un ID unique.

Vous pouvez créer un external_user_id pour un utilisateur avec n'importe quelle chaîne, tant qu'elle est 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'un seul external_user_id, ou session utilisateur, à la fois. Vous ne pouvez pas modifier les autorisations ni les attributs d'un utilisateur en cours de session.

Accéder à plusieurs marques en même temps : que ne 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 dans l'appel create_sso_embed_url présenté précédemment, et crée un nouvel 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 comme celle-ci, ce qui entraîne un workflow incorrect pour l'utilisateur:

Accédez à l'onglet du tableau de bord Pied Piper.
Accédez à l'onglet du tableau de bord Hooli.
Revenez à l'onglet du tableau de bord de Piper.
Cliquez sur le bouton Actualiser du tableau de bord Pied Piper.

... le tableau de bord "Pied Piper" affiche les données de Hooli.

Vous pouvez essayer une approche similaire, mais utilisez plutôt le même utilisateur test_user external_user_id 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 Pied Piper, 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 ?

Appliquer les bonnes pratiques

Pour appliquer l'approche décrite dans la section Approche d'intégration, vous avez besoin d'une seule valeur d'attribut utilisateur qui accorde l'accès à TOUTES les données auxquelles le partenaire doit avoir accès dans l'application. Pour ce faire, utilisez une valeur séparée par une virgule pour l'attribut marque 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 des attributs d'un utilisateur en cas de modification de ses niveaux d'accès aux données. Par exemple, si le partenaire devient propriétaire d'une troisième marque, vous pouvez ajouter cette troisième marque à la liste d'éléments séparés par une virgule que vous avez spécifiée pour l'attribut utilisateur brand. Ainsi, lorsqu'il se déconnecte, puis se reconnecte, 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 un utilisateur peut accéder dans l'application. Mais si je spécifie les attributs utilisateur de cette manière, les données de toutes ces marques s'afficheront dans mon tableau de bord. Comment limiter les résultats d'un tableau de bord spécifique à une marque spécifique ?

La bonne façon de filtrer un tableau de bord particulier consiste à utiliser la fonction ol' filtres de tableau de bord. (Cela peut sembler évident maintenant, mais nous avons vu certains utilisateurs s'en tenir aux attributs utilisateur comme seul moyen d'appliquer des filtres dans le contexte d'intégration, peut-être parce que user_attributes est un paramètre dans l'URL d'intégration signée et que les filtres ne le sont pas.)

Assurez-vous d'exiger une valeur de filtre et d'utiliser l'une des options de commande de sélection unique, comme un 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-là), car les options disponibles dans la liste déroulante sont limitées par les attributs utilisateur:

Préremplir les filtres du tableau de bord

D\'accord. Le tableau de bord peut maintenant être filtré pour une marque spécifique, mais je voudrais 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 hors incorporation. 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 fichier 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é, assurez-vous d'ajouter le filtre à l'URL avant que le chemin ne soit encodé. Certaines valeurs peuvent déjà être encodées dans la chaîne de filtre (par exemple, un espace est encodé en tant que + dans ?Brand=Pied+Piper). Ces valeurs seront donc encodées deux fois dans l'URL finale. Vous pouvez consulter SO embedded dashboard - set dashboard filter as part of URL? (Tableau de bord intégré SO - définir le filtre du tableau de bord dans l'URL ?) Post destiné à la communauté Looker afin de discuter de ces nuances. Si vous ne parvenez toujours pas à appliquer les filtres, vous pouvez également poser vos questions dans ce post destiné à la communauté.

Masquer les filtres du tableau de bord

OK, je vois comment définir les filtres initiaux de 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 par le tableau de bord auquel le partenaire accède dans mon application. Comment puis-je masquer les filtres du tableau de bord ?

Pour cela, vous pouvez utiliser des thèmes. Les thèmes sont une fonctionnalité payante. Si vous ne l'avez pas encore activée sur votre instance Looker, contactez votre équipe commerciale Looker pour qu'elle l'active.

Une fois cette fonctionnalité activée, accédez à la section Commandes du tableau de bord de la page Administration – Thèmes, où vous pouvez décocher 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. Encore une fois, cela s'appliquerait à la target_url de l'appel create_sso_embed_url :

{
  "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 du tableau de bord intégré, y compris certains extraits de code du SDK intégré, consultez ce tutoriel YouTube sur l'intégration de Looker avec des filtres personnalisés.

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

Mais maintenant, comme les valeurs de filtre sont encodées dans les URL cibles respectives intégrées à l'application, le tableau de bord de chaque marque est toujours filtré pour afficher la bonne marque, même lorsque vous passez d'un onglet à un autre.

Tester l'application comme d'autres utilisateurs

L'expérience utilisateur ressemble maintenant beaucoup à celle que j'avais initialement prévue. Toutefois, dans mon cas d'utilisation, le partenaire dispose d'autorisations et de paramètres utilisateur différents de ceux des utilisateurs individuels avec external_user_id=pied_piper et external_user_id=hooli. Les options disponibles dans l'interface utilisateur sont donc différentes, et l'expérience utilisateur est globalement légèrement différente. Je souhaite autoriser un utilisateur à voir tout exactement comme les utilisateurs pied_piper et hooli , comme s'il s'était réellement connecté en tant que ces utilisateurs. Comment puis-je y parvenir ?

Si vous souhaitez qu'un utilisateur puisse effectuer des tests en tant que chaque utilisateur 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 exécute sudo en tant qu'utilisateur Pied Piper, et les URL d'intégration pour external_user_id=hooli lorsque l'utilisateur exécute sudo en tant qu'utilisateur Hooli. Vous pouvez également utiliser le point de terminaison de l'API login_user pour exécuter sudo en tant qu'utilisateur de la marque avec l'API si votre application l'utilise.

Toutefois, si vous revenez au contexte non intégré, sur la page "Admin > Utilisateurs", vous ne pouvez pas exécuter sudo simultanément en tant que plusieurs utilisateurs non intégrés dans plusieurs onglets. La session sudo s'applique à l'ensemble de la fenêtre du navigateur, comme toutes les autres sessions utilisateur. Par conséquent, vous devez concevoir sudo pour sudo comme un seul utilisateur à la fois. Et, si vous y réfléchissez, cette conception est plus cohérente, car elle imite parfaitement l'expérience des utilisateurs avec lesquels vous utilisez sudo. Par exemple, l'utilisateur pied_piper n'a accès qu'au tableau de bord Pied Piper et ne peut pas ouvrir d'autres tableaux de bord dans d'autres onglets. Par conséquent, vous ne devriez pas être en mesure d'ouvrir différents tableaux de bord dans différents onglets lorsque vous exécutez une commande Sudo avec cet utilisateur non plus.

Conclusion

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