Passer à la navigation

Référence de Contrôle d'Accès

Capgo utilise le contrôle d'accès basé sur le rôle (RBAC) pour gérer ce que chaque membre de l'équipe peut faire. Les rôles sont organisés par portée — de l'ensemble de l'organisation jusqu'à un seul paquet.

Pour une présentation visuelle de la gestion des membres dans le tableau de bord, voir Organisation.


Chaque rôl’appartient à une portée qui détermine à quoi il accorde accès.

PortéeS'applique àCas d'utilisation exemple
OrganisationL'ensemble de l'org et tous ses applicationsVotre co-fondateur obtient Super Administrateur ; votre comptable obtient Gestionnaire de facturation
ApplicationUne seule application et ses canauxUn prestataire travaillant sur une application obtient Développeur d'application
CanauxUn seul canal au sein d'une applicationUn ingénieur QA ne gère que le staging canal
PackUne version de bundle uniqueUn évaluateur a besoin d'accès en lecture à une version spécifique de la mise à jour

Un membre peut détenir un rôle par cible de portée — par exemple, un rôle d'organisation, un rôle sur l'application A et un rôle différent sur l'application B.


Ces rôles sont attribués lors de l'invitation d'un membre. Ils accordent l'accès à l'ensemble de l'organisation.

RôleNom interneDescription
Administrateur principalorg_super_adminÉquivalent à propriétaire. Contrôle total, y compris la suppression de l'org, la gestion des factures et le transfert d'applications. Accorde automatiquement au créateur de l'org.
Adminorg_adminAdministration complète — gérer les membres, les applications, les canaux. Impossible de supprimer l'org, de mettre à jour les factures, de transférer les applications ou de promouvoir les utilisateurs en Super Admin.
Gestionnaire des facturesorg_billing_adminAccès aux factures uniquement : afficher et mettre à jour les informations de facturation, les factures et les journaux de suivi de facturation. Pas d'accès aux applications ou aux membres.
Membreorg_memberMatrice de permissions de l'org

Section intitulée « Matrice de permissions de l'org »

Permission
DescriptionSuper AdminOrganization permission matrixAdministrateurGestionnaire des facturesMembre
org.readAfficher l'organisation
org.update_settingsModifier le nom, le logo et l'adresse e-mail de gestion de l'organisation
org.deleteSupprimer définitivement l'organisation
org.read_membersAfficher la liste des membres
org.invite_userInviter de nouveaux membres
org.update_user_rolesChanger les rôles des membres (l'administrateur ne peut pas promouvoir à Super Administrateur — bloqué par la hiérarchie des rôles)
org.read_billingAfficher les informations de facturation et le plan actuel
org.update_billingMettre à jour le moyen de paiement et le plan
org.read_invoicesAfficher les factures
org.read_auditAfficher le journal d'activité de l'organisation
org.read_billing_auditAfficher le journal d'audit spécifique à la facturation

Limité à une seule application. Utilisez ces rôles lorsque vous souhaitez que l'un de vos membres de l'équipe ne travaille que sur une seule application et non sur toute l'organisation.

RôleNom interneDescription
Administrateur d'applicationapp_adminContrôle total d'une application — canaux, appareils, rôles d'utilisateur pour l'application. Impossible de supprimer ou de transférer l'application (ce sont des opérations au niveau de l'organisation).
Développeur d'applicationapp_developerTéléchargement de bundles, gestion d'appareils, déclenchement de builds natives, mise à jour des paramètres de canal. Pas de suppression, pas de modifications des paramètres de l'application, pas de création de canaux.
Téléchargeur d'applicationapp_uploaderAccès en lecture + téléchargement de nouvelles versions de bundles.
Lecteur d'applicationapp_readerLecture seule — statistiques, paquets, canaux, journaux, appareils.
Aperçu d'applicationapp_previewCycle de vie CI lié à l'organisation et à l'application : téléchargez un paquet et créez un canal de prévisualisation. La création de ce canal accorde automatiquement les droits de cycle de vie uniquement pour celui-ci.

Matrice de permissions d'application

Matrice de permissions d'application
PermissionDescriptionAdministrateur d'applicationDéveloppeur d'applicationTéléchargeur d'applicationLecteur d'application
app.readAfficher les détails de l'application, les statistiques et les métadonnées
app.update_settingsModifier les paramètres de l'application
app.read_bundlesAfficher la liste des ensembles de fichiers téléchargés
app.upload_bundleTélécharger une nouvelle version de l'ensemble de fichiers
app.create_channelCréer un nouveau canal
app.read_channelsAfficher les canaux
app.read_logsAfficher les journaux de livraison de mise à jour
app.manage_devicesAttribuer, surcharger ou délier les appareils
app.read_devicesAfficher la liste des appareils
app.build_nativeDéclencher une construction cloud native
app.read_auditAfficher le journal d'activité de l'application
app.update_user_rolesGérer les affectations de rôle scoping l'application
bundle.deleteSupprimer un ensemble de fichiers

Ensemble de permissions d'affichage de l'application

Utilisez

Affichage de l'application pour une clé CI liée à l'organisation et à l'application qui gère le cycle de vie d'une prévisualisation de PR sans accès large à l'application ou à l'organisation. (app_previewet

L' app_preview seuls ces droits d'application sont accordés :

DroitsPermet
app.readLire l'application sélectionnée
app.read_bundlesLire les ensembles de fichiers téléchargés
app.upload_bundleTélécharger un ensemble de fichiers
app.create_channelCréer un canal

When an App Preview key creates a channel, Capgo automatically gives that key a child channel_preview Droits

PermetLire l'application sélectionnée
channel.readLisez le canal créé par la clé
channel.promote_bundleFixez le bundle téléchargé par la clé sur ce canal
channel.deleteSupprimez ce canal

Car app_preview garde app.read, la clé peut lister les métadonnées du canal sélectionné dans l'application. La liaison automatique de l'enfant est un limite de gestion : elle ne concède pas les mutations de cycle de vie pour un canal que la clé n'a pas créé. __CAPGO_KEEP_0__ enregistre la clé de prévisualisation qui a créé chaque canal et téléchargé chaque bundle. Par conséquent, une clé de prévisualisation d'application peut créer chaque canal de prévisualisation non public dont elle a besoin, promouvoir son propre bundle, et supprimer atomiquement ce canal et ce bundle avec

Capgo records the preview key that created each channel and uploaded each bundle. Therefore an App Preview key can create each non-public preview channel it needs, promote its own bundle, and atomically delete that channel and bundle with channel delete --delete-bundleElle ne comprend

, ni la gestion des appareils ni la gestion des rôles app.update_settingsLisez le canal créé par la clé de prévisualisation channel.update_settings, channel.rollback_bundle, gestion de dispositifs forcé, ou générique bundle.delete.


Limité à un seul canal. Utile pour donner un accès ciblé à un canal de version spécifique.

RôleNom interneDescription
Administrateur de canalchannel_adminContrôle total d'un canal : paramètres, promotion/retour en arrière des lots, gestion des appareils forcés.
Voyant de canalchannel_readerLecture seule — le lot actuel, l'historique, les appareils forcés, le journal d'audit.
Aperçu de canalchannel_previewAttribué automatiquement à la clé App Preview qui a créé le canal : lecture, promotion de son propre lot et suppression de ce canal.

Matrice de droits de canal

Matrice de droits de canal
PermissionDescriptionAdministrateur de canalVoyeur de canalAperçu de canal
channel.readAfficher le canal et son bundle actuel
channel.update_settingsModifier les paramètres du canal (tournis de plateforme, politique d'actualisation…)
channel.deleteSupprimer le canal
channel.read_historyAfficher l'historique d'affectation du bundle
channel.promote_bundleDéfinir le bundle actif sur le canal
channel.rollback_bundleRevenir à une version précédente du bundle
channel.manage_forced_devicesForcer des appareils spécifiques à ce canal
channel.read_forced_devicesAfficher la liste des appareils forçés
channel.read_auditAfficher le journal d'activité du canal

Rôles de bundle

Rôles de bundle

Attribués à une seule version du bundle. Rarement nécessaire — la plupart des équipes utilisent des rôles d'application au lieu de ceux-ci.

RôleNom interneDescription
Administrateur de bundlebundle_adminLecture, mise à jour des métadonnées et suppression d'un bundle spécifique.
Voyant de bundlebundle_readerAccès en lecture seule à un bundle spécifique.

Surcharge de permission de canal (Tableau de bord)

Sous-titre « Surcharge de permission de canal (Tableau de bord) »

Dans le tableau de bord, l'accès au canal est déterminé par le rôle de l'application de l'utilisateur par défaut. Pour un contrôle plus granulaire, vous pouvez surcharger les permissions de canal spécifiques par utilisateur ou groupe sans modifier leur rôle d'application.

Les surcharges sont configurées à partir de l'application dans l'onglet Accès bouton de permissions de canal (icône de bouclier) à côté d'un utilisateur. Voir Organisation — Surcharge des permissions de canal pour une présentation visuelle.

PermissionDescriptionComportement par défaut
LireAfficher le canal et son bundle actuelHérité de l'identité d'application
HistoriqueAfficher l'historique d'affectation du bundleHérité de l'identité d'application
Associer un bundleDéfinir ou modifier le bundle actif sur le canalHérité de l'identité d'application

Chaque autorisation peut être définie sur :

  • Par défaut — hériter de l'identité d'application (la valeur par défaut)
  • Autoriser — accorder explicitement, en fonction ou non de l'identité d'application
  • Interdire — bloquez explicitement, quel que soit le rôle de l'application

Cela vous permet, par exemple, de donner à un Lecteur d'application la possibilité de lier des ensembles sur le staging canal sans les promouvoir en Développeur d'application.


Les rôles forment une hiérarchie. Un rôle parent hérite de toutes les autorisations de ses enfants. Cela signifie que org_admin peut faire tout ce que app_admin peut faire, qui à son tour peut faire tout ce que channel_admin peut faire, et ainsi de suite.

Super Admin (org_super_admin)
└── Admin (org_admin)
└── App Admin (app_admin)
├── App Developer (app_developer)
│ └── App Uploader (app_uploader)
│ └── App Reader (app_reader)
├── Bundle Admin (bundle_admin)
│ └── Bundle Viewer (bundle_reader)
└── Channel Admin (channel_admin)
└── Channel Viewer (channel_reader)

Comment ça marche en pratique :

  • Un Administrateur au niveau de l'organisation peut faire tout ce que peut faire un Administrateur d'application sur chaque application de l'organisation.
  • Un Administrateur d'application sur une application spécifique peut faire tout ce que peut faire un Administrateur de canal sur chaque canal de cette application.
  • Un Développeur d'application peut faire tout ce que peut faire un Chargé d'upload d'application , plus encore.

La hiérarchie ne s'écoule que vers le bas — un channel_admin ne gagne jamais les permissions au niveau de l'organisation, même s'il détient également un rôl’au niveau de l'application.


Plutôt que d'attribuer des rôles à chaque utilisateur individuellement, vous pouvez créer groupes et affectez des rôles au groupe. Chaque membre du groupe hérite automatiquement de ces rôles.

  • Un groupe appartient à une organisation — il ne peut pas couvrir plusieurs organisations.
  • Les groupes peuvent conserver des liens de rôl’à n'importe quel niveau: organisation, application, canal ou paquet. Par exemple, un groupe peut être affecté du Rôle développeur d'application rôle sur l'application A et le Administrateur de canal rôle sur le staging canal de l'application B.
  • Lorsque les autorisations d'un utilisateur sont évaluées, toutes ses adhésions de groupe sont résolues de manière transparente. Si l'un de ses groupes accorde la permission requise, l'accès est autorisé.
  • Un utilisateur peut appartenir à plusieurs groupes, et les autorisations de tous les groupes sont additives.
  • Les autorisations basées sur les groupes ne s'appliquent qu'aux principaux d'utilisateur — les clés API ne héritent pas de rôles de groupe.
Étapes de scénarioSans groupesAvec groupes
5 ingénieurs QA ont besoin d'accès développeur à 3 applications15 liens de rôl’individuels1 groupe + 3 liens de rôle
Quelqu'un rejoint l'équipe QAAjouter 3 liens de rôle manuellementLes ajouter au groupe
Quelqu'un quitte l'équipe QASupprimer 3 liens de rôle manuellementLes supprimer du groupe

Toutes les endpoints de groupe nécessitent une authentification et sont servis sous /private/groups.

Lister les groupes

Fenêtre de terminal
Copier dans le presse-papier
curl -X GET "https://api.capgo.app/private/groups/<ORG_ID>" \
-H "authorization: <API_KEY>"

la permission. org.read_members Créer un groupe

Section intitulée “Créer un groupe”

Fenêtre de terminal
Toutes les endpoints de groupe nécessitent une authentification et sont servis sous
curl -X POST "https://api.capgo.app/private/groups/<ORG_ID>" \
-H "authorization: <API_KEY>" \
-H "Content-Type: application/json" \
-d '{
"name": "QA Team",
"description": "Quality assurance engineers"
}'

Exige org.update_user_roles la permission (Administrateur Supérieur ou Administrateur).

Mettre à jour un groupe

Fenêtre de terminal
Copier dans le presse-papiers
curl -X PUT "https://api.capgo.app/private/groups/<GROUP_ID>" \
-H "authorization: <API_KEY>" \
-H "Content-Type: application/json" \
-d '{
"name": "QA Team",
"description": "Updated description"
}'

Section intitulée « Supprimer un groupe »

Appflow Plugins ou
Fenêtre de terminal
curl -X DELETE "https://api.capgo.app/private/groups/<GROUP_ID>" \
-H "authorization: <API_KEY>"

La suppression d'un groupe supprime également toutes ses liaisons de rôle. Les membres ne sont pas supprimés de l'organisation.

Fenêtre de terminal
curl -X GET "https://api.capgo.app/private/groups/<GROUP_ID>/members" \
-H "authorization: <API_KEY>"
Fenêtre de terminal
curl -X POST "https://api.capgo.app/private/groups/<GROUP_ID>/members" \
-H "authorization: <API_KEY>" \
-H "Content-Type: application/json" \
-d '{ "user_id": "<USER_UUID>" }'

L'utilisateur doit déjà être membre de l'organisation. L'ajout d'un membre existant est une opération sans effet.

Fenêtre de terminal
curl -X DELETE "https://api.capgo.app/private/groups/<GROUP_ID>/members/<USER_UUID>" \
-H "authorization: <API_KEY>"

Fenêtre de terminal
curl -X GET "https://api.capgo.app/organization/members" \
-H "authorization: <API_KEY>" \
-H "Content-Type: application/json" \
-d '{ "orgId": "<ORG_ID>" }'

Réponse :

[
{
"uid": "user-uuid",
"email": "alice@example.com",
"image_url": "https://...",
"role": "org_admin",
"is_tmp": false
}
]
Fenêtre de terminal
curl -X POST "https://api.capgo.app/organization/members" \
-H "authorization: <API_KEY>" \
-H "Content-Type: application/json" \
-d '{
"orgId": "<ORG_ID>",
"email": "bob@example.com",
"invite_type": "org_admin"
}'

Valeurs acceptées pour invite_type:

ValeurRôl’attribué
org_super_adminAdministrateur principal
org_adminAdministrateur
org_billing_adminGestionnaire des factures
org_memberMembre
Fenêtre de terminal
curl -X DELETE "https://api.capgo.app/organization/members" \
-H "authorization: <API_KEY>" \
-H "Content-Type: application/json" \
-d '{
"orgId": "<ORG_ID>",
"email": "bob@example.com"
}'

Onglet terminal
npx @capgo/cli organization list --apikey <API_KEY>
Onglet terminal
npx @capgo/cli organization members <ORG_ID> --apikey <API_KEY>

Les rôles intégrés couvrent la plupart des structures d'équipe. La création de rôles personnalisés est prévue dans notre feuille de route — si cela est quelque chose dont votre équipe a besoin, nous contacterVotre cas d'utilisation aidera directement à prioriser cette fonctionnalité.

Si vous utilisez Contrôle d'accès pour planifier les opérations de tableau de bord et API API Overview API Overview pour les détails d'implémentation dans __CAPGO_KEEP_0__ Overview Introduction API Keys pour les détails d'implémentation dans les API clés, Appareils pour les détails d'implémentation dans les Appareils, et Bundles pour les détails d'implémentation dans les Bundles.