Deux identifiants Tableau qui font deux métiers différents. L’un porte les permissions d’une personne. L’autre étend une capacité de la plateforme. Choisir le bon garde aux commandes de qui voit quoi un modèle de permissions que vous avez mis des années à construire.
Mis à jour · 5 min de lecture
Ce sont deux routes vers deux endroits différents. Les traiter comme interchangeables est l’erreur d’identifiant la plus lourde de conséquences dans une intégration Tableau. L’erreur est fréquente, parce que les deux fonctionnent.
La règle ici est écrite dans le code, et énoncée dans le module qui la met en œuvre. Chaque utilisateur se connecte avec son propre jeton Tableau. Ce jeton porte ses permissions Tableau exactes. Il est la frontière de gouvernance pour chaque lecture, chaque écriture, et chaque appel d’assistant ou d’outil fait pour lui.
La connexion appartient au seul jeton personnel. Un chemin en un clic qui la contournait a existé à un moment, et il a été retiré délibérément. Le résolveur a été supprimé, et la passerelle refuse maintenant une tentative de connexion qui a la forme d’un JWT.
La raison est pratique plutôt qu’architecturale. Laissez un identifiant de service connecter une personne, et chaque action qui suit porte les permissions du compte de service plutôt que celles de la personne. Le modèle de permissions Tableau que votre équipe a mis des années à construire cesse alors de décider qui peut voir quoi.
Elle couvre une capacité de la plateforme : une personne est déjà connectée, et la plateforme elle-même a besoin d’un jeton qui lui soit propre. L’intégration est l’exemple vivant. Une vraie vue Tableau rendue à l’intérieur d’une autre surface a besoin d’un jeton que l’API d’intégration acceptera, et un jeton personnel n’a pas la bonne forme pour cela.
Le deuxième point produit des tickets de support qui ressemblent à une instabilité du produit. Ce sont des collisions d’identifiants. Cela vaut la peine de le vérifier en premier chaque fois qu’une tâche planifiée et une personne semblent se gêner mutuellement.
Les secrets dans cette suite ne durent que le temps d’une session. Cela tient proprement jusqu’à ce que quelque chose doive s’exécuter à deux heures du matin sans personne de connecté. Un secret de session ne peut pas exister à cette heure-là, par définition.
Il y a une exception, et elle est explicite plutôt qu’implicite. Un opérateur clique pour verrouiller un jeton pour les exécutions planifiées. Il est chiffré au repos sous une clé machine, jamais journalisé, et jamais renvoyé au navigateur. L’appel de description ne renvoie que le nom du jeton. Un clic le retire. L’interface recommande un jeton d’automatisation dédié, pour la raison de collision évoquée plus haut.
Une exception sur laquelle une personne doit cliquer est une exception que quelqu’un peut retrouver plus tard. Une exception qui se produit automatiquement est une exception que personne ne peut auditer, et à laquelle, un jour, personne ne se souvient d’avoir consenti.
Une tâche planifiée peut essayer d’abord un jeton personnel et se rabattre sur un JWT de Connected App. C’est une conception sensée. Elle peut aussi cacher un identifiant cassé pendant des mois, parce que de l’extérieur l’exécution continue de réussir.
La correction est petite et elle compte. Enregistrez quel identifiant a réellement authentifié, et affichez-le sur la ligne. Un repli qui se produit de façon invisible est un repli que personne ne répare jamais. La première fois que quelqu’un en entend parler, c’est le jour où le repli échoue à son tour.
Quatre vérifications, et la quatrième est celle sur laquelle il vaut la peine de prendre son temps. Tout le reste de cette page découle du fait de l’avoir bien faite.
Une personne s’en va. Son nom reste sur des classeurs, des planifications et des abonnements, et plusieurs d’entre eux tombent en panne sans un bruit. Ce qu’elle détient, ce qui casse, et l’ordre qui garde la licence récupérable.
La règle approuver pour exécuter, en mots simples. L’assistant lit, explique et propose, et une personne possède le chemin d’écriture. Ce que cela coûte, ce que cela rapporte, et trois questions à poser à toute fonctionnalité d’IA.
Une affirmation est une phrase. Une preuve est quelque chose qu’une seconde personne peut vérifier sans vous demander. Ce qu’une piste d’audit doit contenir, ce qu’un hachage prouve réellement, et ce qu’il faut exiger de tout outil qui prétend en produire une.