Access Explorer

À quoi sert cet écran

Access Explorer répond à une seule question : cet utilisateur peut-il faire telle chose, et sinon, pourquoi ? Il résout un nom d’utilisateur face à une permission et vous donne le résultat — vous n’avez donc jamais à le déduire en lisant rôles et policies vous-même, ni, bien pire, à demander à l’utilisateur d’essayer pour voir.

C’est l’outil vers lequel toutes les autres pages des Paramètres vous renvoient lorsqu’un accès est refusé.

Avant de commencer

Access Explorer est réservé aux administrateurs. Il est contrôlé séparément du reste des Paramètres : détenir platform-settings.*.read vous donne accès à Settings, mais l’entrée Access Explorer n’apparaît que pour les administrateurs.

Si elle ne figure pas dans votre sous-menu, vous n’êtes pas administrateur. Demandez à l’un d’eux de faire la recherche : cela lui prend quelques secondes.

Ouvrir l’écran

1. Settings dans la barre latérale.
2. Access Explorer, en bas du sous-menu.

URL directe : /platform-settings/access-explorer

L’interface

📸 Capture d’écran : Access Explorer après une recherche. Repères : (1) le champ du nom d’utilisateur, (2) le champ de permission, (3) les sélecteurs de portée éventuels, (4) le panneau de résultats indiquant autorisé ou refusé.

Les chaînes de permission sont comparées littéralement. platform-settings.user.create et platform-settings.users.create sont deux chaînes différentes, et la seconde renverra « refusé » pour tout le monde. Copiez la chaîne depuis la page qui l’a nommée plutôt que de la saisir de mémoire.

Procédures

Comprendre pourquoi un utilisateur ne peut pas faire quelque chose

1. Settings › Access Explorer.
2. Saisissez le nom d’utilisateur exactement tel qu’il figure dans Utilisateurs.
3. Saisissez la chaîne de permission. La page qui a signalé le problème la nomme — une réponse 403 la mentionne dans son message.
4. Renseignez la portée si la permission est cantonnable : le cluster ou l’environnement réellement visé.
5. Lisez le résultat.

Confirmer qu’une modification a fonctionné

Après avoir accordé un accès, refaites la recherche avant d’annoncer que c’est fait. Cela prend quelques secondes et rattrape les erreurs de cantonnement, qui sont autrement invisibles.

Vérifier qu’un refus est intentionnel

Avant un audit ou un départ, vérifiez que les permissions que vous croyez refusées le sont réellement. Un refus vérifié vaut nettement mieux qu’un refus supposé.

Scénario

Un développeur signale « permission refusée » sans pouvoir en dire plus.

1. Demandez-lui deux choses : l’URL exacte sur laquelle il se trouvait, et le message d’erreur. Un 403 Fenwave nomme la permission requise et le nom d’utilisateur résolu — c’est votre point de départ, et cela évite de deviner.
2. Settings › Access Explorer, saisissez ce nom d’utilisateur et cette permission.
3. Renseignez la portée correspondant au cluster ou à l’environnement concerné.
4. Lisez le résultat :
   • Refusé, y compris sans portée → il ne l’a réellement pas. Trouvez le bon rôle, ou créez-en un.
   • Refusé ici, autorisé sans portée → la permission est accordée mais la policy ne couvre pas ce cluster ou cet environnement. Élargissez le statement délibérément, à cette portée seulement.
   • Autorisé → il l’a bien, l’échec est donc ailleurs. La cause habituelle est le cache de permissions de la session : demandez-lui de recharger. Si le problème persiste après rechargement, cessez de le traiter comme un problème de permissions et regardez la fonctionnalité elle-même.
5. Après toute modification, refaites la recherche pour confirmer.

La troisième branche de l’étape 4 mérite d’être retenue. « Autorisé ici mais en échec là-bas » signifie presque toujours une session périmée, et le poursuivre comme un problème de permissions fait perdre beaucoup de temps.

En cas de problème

Pour aller plus loin

• Comment fonctionnent les permissions — ce que signifie le résultat
• Policies — où effectuer la correction