Historique d'activité
Qui a changé quoi, avec les valeurs avant et après — lisible uniquement parce que chaque personne a son propre identifiant.
Ouvrir le sujetAide CDN.com.tr
Rôles d'équipe : viewer, editor et owner
Donnez à chaque collègue son propre identifiant et le rôle le plus restreint qui lui permette de faire son travail. Le même rôle est appliqué sur l'API, donc un jeton bearer ne peut jamais faire plus que la personne à qui il appartient.
Organisation, permissions, support
Rôles d'équipe : viewer, editor et owner
Donnez à chaque collègue son propre identifiant et le rôle le plus restreint qui lui permette de faire son travail. Le même rôle est appliqué sur l'API, donc un jeton bearer ne peut jamais faire plus que la personne à qui il appartient.
Chemin dans le panneau
- Panneau de gestion
- Autorisation
- Créer un utilisateur
- Rôle
Prerequis
- Seul le propriétaire du compte peut créer des sous-utilisateurs et définir des rôles.
- Chaque personne a besoin de sa propre adresse e-mail ; la piste d'audit ne vaut rien si deux personnes en partagent une.
- Décidez du rôle avant de créer l'utilisateur — c'est plus simple que d'expliquer une lacune de permission plus tard.
Modele de decision
De quel rôle cette personne a-t-elle besoin ?
Choisissez selon le minimum qui la débloque, pas selon l'ancienneté.
- Viewer : reporting, supervision, une agence qui ne lit que la consommation et les chiffres de cache.
- Editor : le développeur ou l'éditeur qui purge après un déploiement, modifie les règles de diffusion, et gère le DNS et les certificats.
- Owner : vous, et toute personne à qui vous confieriez la facturation et l'ajout d'autres utilisateurs.
Un identifiant ou un par personne ?
Ce choix décide si le journal d'audit peut un jour répondre à une question.
- Un identifiant par personne : chaque ligne de l'historique d'activité nomme une vraie personne.
- Un identifiant partagé : chaque action se ressemble, et retirer une personne signifie changer le mot de passe pour tout le monde.
Guide etape par etape
Créez l'utilisateur
Autorisation est la page qui possède les sous-utilisateurs pour l'ensemble du client, pas par compte.
- Ouvrez Autorisation et cliquez sur Créer un utilisateur.
- Renseignez prénom, nom, e-mail, téléphone et le mot de passe deux fois.
- Ne validez pas encore — la liste des rôles se trouve en bas du même formulaire.
Resultat attendu: Le formulaire du nouvel utilisateur est rempli et le tableau des rôles est visible sous les champs de mot de passe.
cdnctl equivalent
POST /api/subusersDéfinissez le rôle
Le tableau des rôles liste les rôles avec un interrupteur inactif/actif sur chacun. Activez celui dont la personne a besoin.
- Activez Viewer (lecture seule) pour quelqu'un qui ne fait que lire les rapports.
- Activez Editor pour quelqu'un qui purge, ou modifie les règles de diffusion, le DNS ou les certificats.
- Ne laissez tout désactivé que si vous voulez un viewer — c'est ce vers quoi un rôle vide bascule par défaut.
- Cliquez sur Créer l'utilisateur.
Resultat attendu: L'utilisateur est créé avec exactement le rôle choisi, et peut se connecter avec ses propres identifiants.
cdnctl equivalent
GET /api/rolesConfirmez que la limite tient
Vérifiez depuis le nouveau compte, pas depuis le vôtre. C'est une vérification de deux minutes qui évite une mauvaise surprise.
- Faites se connecter la personne et lui ouvrir les pages dont elle a besoin.
- Demandez à un viewer d'essayer d'enregistrer quelque chose et confirmez qu'il est refusé.
- Ouvrez Historique d'activité et confirmez que ses actions sont enregistrées sous son propre nom.
Resultat attendu: La personne peut faire son travail, est bloquée sur tout le reste, et chaque action qu'elle effectue est attribuable.
cdnctl equivalent
GET /api/accounts/<account_uuid>/activities?per_page=25Verification
- Un viewer peut ouvrir toutes les pages mais ne peut rien enregistrer sauf son propre profil et mot de passe.
- Un editor peut purger et modifier les règles de diffusion mais n'a aucune action de sous-utilisateur ou de facturation.
- Un jeton émis pour un sous-utilisateur est refusé sur les points de terminaison que son rôle ne couvre pas.
- L'historique d'activité nomme le sous-utilisateur, pas le propriétaire, après qu'il a effectué un changement.
Cas d'usage
Deux ou trois personnes travaillent sur le même compte CDN : l'une publie et doit purger, l'autre ne fait que lire les rapports, et vous seul devriez pouvoir ajouter des utilisateurs ou toucher à la facturation. Un mot de passe partagé donne aux trois le même pouvoir et rend le journal d'audit inutile.
Workflow rapide
- Ouvrez Autorisation et créez un utilisateur pour chaque personne plutôt que de partager un identifiant.
- Définissez le rôle sur le nouvel utilisateur : viewer pour la lecture seule, editor pour les opérations quotidiennes, owner pour le contrôle total.
- Faites se connecter la personne et confirmez qu'elle peut faire son travail et rien de plus.
- Vérifiez ensuite Historique d'activité : ses actions apparaissent désormais sous son propre nom.
Verifications
- Viewer : lit toutes les pages, et peut modifier son propre profil et mot de passe. Aucune autre écriture.
- Editor : purge, règles de diffusion, DNS, certificats et noms d'hôte. Pas de gestion des sous-utilisateurs, pas de facturation, pas de suppression de compte.
- Owner : tout, y compris les utilisateurs et la facturation. C'est le rôle avec lequel le compte s'est inscrit.
- Laisser le rôle vide fait de l'utilisateur un viewer. Un nouvel utilisateur n'est jamais créé avec plus de pouvoir que celui que vous avez accordé.
- L'API applique les mêmes règles. Un jeton viewer ne peut pas écrire, et un jeton editor est refusé sur les points de terminaison réservés à owner.