Rôles & permissions

CodeCourier utilise un système de contrôle d’accès basé sur les rôles (RBAC) avec trois rôles distincts : Owner, Admin et Member. Chaque rôle hérite de toutes les permissions des rôles en dessous, créant une hiérarchie claire. Cette page documente exactement ce que chaque rôle peut faire et fournit des recommandations pour l’attribution des rôles.

Hiérarchie des rôles

Le modèle de permissions suit une hiérarchie stricte :

Owner > Admin > Member

Chaque rôle inclut toutes les permissions des rôles en dessous. Un Owner peut faire tout ce qu’un Admin peut faire, et un Admin peut faire tout ce qu’un Member peut faire.

Définitions des rôles

Owner

L’Owner est le créateur du projet et dispose d’un accès sans restriction à toutes les fonctionnalités et paramètres. Un projet a toujours au moins un propriétaire, et cette contrainte est appliquée au niveau de la base de données - le dernier propriétaire restant ne peut pas être supprimé ni rétrogradé.

Capacités exclusives à l’Owner :

• Changer le rôle de n’importe quel membre (y compris promouvoir d’autres personnes en Owner)
• Supprimer d’autres propriétaires du projet
• Supprimer entièrement le projet
• Transférer la propriété en promouvant un autre membre et en se rétrogradant

Admin

Les Admins sont des membres de confiance de l’équipe qui peuvent gérer les opérations quotidiennes du projet, y compris la gestion des membres et la configuration des paramètres. Ils disposent de presque toutes les permissions d’un Owner, à l’exception des changements de rôle et des actions destructrices de niveau propriétaire.

Capacités de l’Admin (en plus de celles du Member) :

• Inviter de nouveaux membres au projet
• Supprimer des membres du projet (sauf les propriétaires)
• Annuler les invitations en attente
• Configurer les paramètres du projet (clés API, prompts système, variables d’environnement)

Member

Les Members sont des participants réguliers de l’équipe qui peuvent utiliser toutes les fonctionnalités du projet mais ne peuvent pas gérer l’équipe ni les paramètres critiques. C’est le rôle par défaut pour les nouvelles invitations.

Capacités du Member :

• Voir toutes les ressources du projet (sandboxes, runs, workflows, personas, issue sessions, learnings)
• Créer et gérer leurs propres sandboxes et runs
• Créer et configurer des workflows et des personas
• Démarrer et gérer des issue sessions
• Voir et accepter/refuser leurs propres invitations
• Voir la liste des membres
• Accéder aux données d’analytique et d’utilisation du projet

Matrice des permissions

Mécanisme d’application

Les permissions sont appliquées côté serveur dans chaque query et mutation Convex. Le backend utilise des fonctions d’assistance d’authentification partagées qui vérifient à la fois l’identité et l’autorisation avant d’exécuter toute opération :

• getProjectForMember(ctx, projectId) - Vérifie que l’utilisateur actuel est un membre actif (non en attente) du projet. Utilisée par les queries qui nécessitent un accès de base au projet.
• requireProjectAdmin(ctx, projectId) - Vérifie que l’utilisateur actuel est un admin ou un propriétaire du projet. Utilisée par les mutations qui gèrent les membres et les paramètres.
• requireProjectOwner(ctx, projectId) - Vérifie que l’utilisateur actuel est un propriétaire du projet. Utilisée par les mutations qui changent les rôles et effectuent des opérations destructrices.

Ces vérifications s’exécutent à chaque requête, garantissant que même si le frontend ne parvient pas à masquer un bouton, le backend rejette les opérations non autorisées.

Contraintes de sécurité

Plusieurs règles de sécurité préviennent les scénarios de verrouillage accidentel :

• Protection du dernier propriétaire - S’il ne reste qu’un seul propriétaire, ce propriétaire ne peut pas être supprimé ni rétrogradé. Le système vérifie le nombre de propriétaires avant d’autoriser une rétrogradation ou une suppression.
• Garde-fou d’auto-rétrogradation - Un propriétaire peut se rétrograder, mais seulement s’il y a au moins un autre propriétaire pour maintenir la gouvernance du projet.
• Garde-fou de suppression inter-rôles - Un admin non propriétaire ne peut pas supprimer un propriétaire. Seuls les propriétaires peuvent supprimer d’autres propriétaires.

Bonnes pratiques

Commencez par le moindre privilège

Attribuez le rôle Member par défaut lors de l’invitation de nouveaux utilisateurs. Promouvez en Admin uniquement lorsque la personne a besoin de gérer l’équipe ou de configurer les paramètres du projet. Réservez le rôle Owner aux utilisateurs qui ont besoin d’un contrôle total du projet.

Maintenez plusieurs propriétaires

Pour les projets de production, attribuez au moins deux propriétaires. Cela garantit que l’accès au projet est maintenu même si un propriétaire devient indisponible. Cela permet également le transfert de propriété sans intervention externe.

Examinez régulièrement l’adhésion

Examinez périodiquement la liste des membres et supprimez les utilisateurs qui n’ont plus besoin d’accès. Contrairement à certains systèmes, CodeCourier n’a pas d’expiration automatique des rôles, donc une revue manuelle est l’approche recommandée.

Prochaines étapes