Concepts

RBAC et approbations

Les rôles, les portées et la manière dont les publications de production sont bloquées.

Le modèle d'accès de Showly comporte trois couches : rôles sur l'espace de travail, portées sur l'action et approbations pour les modifications ayant un impact sur la production. Cette page explique comment chaque couche est composée.

Rôles

Le rôle d'un utilisateur est défini au niveau de l'espace de travail :

Rôle	Peut faire
`owner`	Accès complet, y compris les membres, les jetons, la facturation, la sécurité de l'espace de travail, l'aperçu, la publication en direct, la suppression et la restauration.
`member`	Créez des projets et des sites, gérez les fonctionnalités du produit, créez un aperçu et publiez en direct ; pas de membres ni de facturation.
`developer`	Gérer et publier les sites existants et Aperçu ; ne peut pas créer de projets ni gérer la gouvernance de l’espace de travail.
`viewer`	Lisez les sites, les projets, les déploiements, les notifications et les données d'affiliation.
`billing`	Lire des projets/sites et gérer la facturation, les méthodes de paiement, les remboursements, les coupons et l'audit financier ; aucun site n'écrit.

Les espaces de travail peuvent également définir des rôles personnalisés (via les autorisations de rôle) lorsque les cinq éléments intégrés ne conviennent pas.

Un utilisateur peut avoir au maximum un rôle par espace de travail. Les adhésions aux espaces de travail sont indépendantes : être propriétaire d’un espace de travail ne vous donne rien dans un autre.

Portées

Les jetons MCP, les jetons API et les jetons de service portent des portées qui constituent un sous-ensemble strict de ce que leur émetteur peut accorder. Une portée décrit une paire resource:verb. Les dix scopes MCP sont :

project:read
site:read
site:write
preview:read
preview:create
checks:run
publish:request
logs:read
template:read
template:create

En gros, viewer correspond aux étendues de lecture de base. member et developer recevoir les étendues Preview/checks/publish/log utilisées par la boucle d'agent ; member crée en outre des projets et dispose d'une gestion de produit plus large accès. billing reçoit les étendues financières mais aucune écriture de site ou de déploiement. Seul owner comporte les membres, les invitations, les jetons, la sécurité de l'espace de travail et l'intégralité étendue de facturation définie.

Un jeton ne peut faire que ce qui est dans sa portée, quel que soit celui qui l'a émis. L'émission d'un jeton avec une portée que vous n'avez pas est rejetée.

Voir la référence de portée pour le mappage canonique portée-outil.

Approbations

Les approbations déclenchent les changements ayant un impact sur la production. La règle la plus courante : la publication en production nécessite N approbations d'un ensemble de rôles autorisés.

Valeurs par défaut de la demande d'approbation :

requiredApprovals est par défaut 1.
allowedRoles est par défaut une liste vide, ce qui signifie que n'importe quel rôle peut approuver.
Un rejet est définitif : une demande rejetée ne peut pas être réapprouvée.

Lorsqu'un agent appelle request_publish sur MCP, la demande de publication résultante est créé avec requiredApprovals: 1 et allowedRoles: ["owner", "member"]. Ce flux nécessite le droit approvalWorkflows.

Personnalisez par site ou par espace de travail dans Paramètres de l'espace de travail → Politique d'approbation.

Séparation des tâches

Un utilisateur ne peut pas approuver sa propre demande. Ceci est appliqué au niveau du modèle de données : si vous avez proposé la publication, une autre personne disposant d'un rôle autorisé doit l'approuver.

Ce qui est audité

Chaque action — agent, humain, API — écrit une ligne d'audit :

acteur (identifiant utilisateur + rôle à ce moment-là, ou MCP identifiant client + scopes)
action (le verbe de portée + l'identifiant de la ressource)
résultat (allowed, denied, pending_approval, approved, rejected)
quand

Les lignes d'audit sont uniquement ajoutées et disponibles via les surfaces d'audit de Showly. L’export SIEM externe n’est actuellement pas promis.

Remplacements d'urgence

Showly n'expose actuellement pas de contournement de publication emergency via MCP ou le flux Web public. Le travail d'urgence est géré en accélérant l'approbation d'un aperçu ready, puis en le publiant explicitement ; L’inscription à OTP n’est pas requise. Si un futur chemin bris de glace est ajouté, il devra :

toujours passer une approbation (la porte est une approbation, pas une autorisation).
écrivez une ligne d'audit spéciale emergency=true.
ouvrir automatiquement une tâche post-mortem de suivi.