Rôles et actions : la matrice complète

English · Type : référence · Public : auteur, administrateur · Contexte : Studio hébergé · Statut : prête · S'applique depuis : 4.4.0

Le Studio Server (Studio d'équipe hébergé) · contrat : expérimental · vérifié par la CI (matrice de support de la 4.4.0, 2026-10-23) : Postgres, S3 et Keycloak en CI ; Chromium et Firefox (job studio-hosted) ; WebKit sous macOS, à la main seulement · vérifications automatiques : jobs studio-hosted, studio-install-smoke ; plan de CI studioHosted ; 3 fichiers de tests · passes humaines : studio-hosted pas faite (#149), studio-collab pas faite (#150), studio-preview pas faite (#166), studio-assets-hosted pas faite (#167), studio-mcp-remote pas faite (#196), studio-oidc-generic pas faite (#197) · limites connues : roles-fixed

Sur un Studio d'équipe, chaque membre a un rôle : owner, dev ou reviewer. Cette page liste chaque route du Studio Server et le rôle qu'elle demande, lus dans le code : le contrôle d'accès (auth/gate.ts), le rôle de chaque route d'API (roleFor dans http.ts), les routes de l'owner (auth/routes.ts) et la table de l'API (ops/routes.ts).

Comment la lire

• Les rôles sont ordonnés : reviewer < dev < owner. Une route qui demande dev est ouverte aux owners aussi.
• La règle : un GET (et un POST qui ne fait que lire, comme une vérification) demande un reviewer ; toute autre écriture demande un dev ; les membres, les invitations, l'audit et quelques actions sur le jeu entier demandent un owner. Les exceptions figurent dans chaque tableau.
• En dessous du rôle demandé, la réponse est 403 this needs the role <rôle>. Une personne connectée qui n'est pas membre reçoit 403 not a member of this project. Sans session ni jeton : 401.
• Le rôle est vérifié à chaque requête, avec le cookie de session (le navigateur) ou un jeton d'accès Bearer (la CLI, les scripts, le MCP). Un rôle changé ou un membre retiré prend effet à sa requête suivante.
• Les routes ci-dessous sont sous l'URL publique du Studio. L'origine du jeu (playUrl) a ses propres règles, à la fin.

owner

Tout ce que peut un dev, plus : les membres, leurs rôles et leurs sessions, les invitations, le journal d'audit ; reprendre un pan ; le bail exclusif à la main ; pousser vers Git et importer depuis Git ; la montée de version du moteur ; reconstruire à neuf un build publié ; faire entrer les notes comme commentaires ; annuler le job de n'importe qui. Le dernier owner ne peut être ni rétrogradé ni retiré.

dev

Écrit le jeu, pan par pan : salles, textes, valeurs, storyboard, regroupements de la carte, notes, voix, uploads et découpes, Prepare, annulation et rétablissement de ses propres opérations, publication d'un build, demande d'une bissection, prise et rendu de pans. Résout n'importe quel fil de commentaires. Annule les jobs qu'il a lancés.

reviewer

Lit et joue : toutes les lectures du jeu et du Studio, les vérifications (validateur, solveur, lint…), les aperçus et les builds, le flux en direct. N'écrit aucun fichier du jeu. Commente, modifie ses propres commentaires, et résout ses propres fils. Ne tient aucun bail.

Le jeu : lectures et modifications

Vérifications et historique

Ces POST ne font que lire : ils prennent leurs options dans un corps, ne demandent aucun bail, et ne sont jamais refusés pour un pan.

Direct, présence et pans

Commentaires

Seul son auteur change le texte d'un commentaire, quel que soit son rôle (403 sinon). Aucune route ne supprime un commentaire.

Assets, jobs et builds

Membres, Git et moteur

Voir Gérer les membres, Le jeu dans Git et Mettre à jour le moteur d'un jeu hébergé.

Le MCP distant

POST /mcp n'accepte qu'un jeton d'accès Bearer (jamais le cookie de session), d'un membre : un reviewer au moins. Chaque outil est ensuite une requête à la même /api avec le jeton de l'appelant, donc un outil demande le rôle de sa route : l'agent d'un reviewer lit et vérifie, celui d'un dev écrit. Voir MCP distant.

Les routes sans rôle

Chaque route /auth/… accepte au plus 30 requêtes par minute et par adresse ; au-delà elle répond 429 avec Retry-After: 60.

L'origine du jeu

Sur playUrl, aucune API du Studio ni route /auth ne répond. Chaque chemin demande une session de jeu, créée à partir d'un ticket que la session de navigateur d'un membre a demandé (POST /api/play-ticket) : n'importe quel rôle. La session de jeu dure 15 minutes, glissantes, et elle est vérifiée à chaque requête contre la session Studio et l'appartenance du membre. Avec publicBuilds: true dans la configuration, /play/… et /icons/… (les builds publiés) s'ouvrent sans session, à tout le monde.

Les refus qui ne tiennent pas au rôle

Même avec le bon rôle, une écriture peut être refusée :

• 423 : le pan est tenu par quelqu'un d'autre, ou le jeu entier l'est (423).
• 409 : le fichier a changé depuis votre lecture (409), ou le dernier owner serait rétrogradé ou retiré.
• 403 forbidden : une écriture du navigateur sans l'Origin exacte, l'en-tête X-Studio-Request: 1 et un corps JSON.
• 503 avec Retry-After : l'instance ne sert pas encore les écritures (un redéploiement), ou le fournisseur d'identité n'a pas confirmé votre session depuis 15 minutes (suspended).
• 429 : trop d'authentifications refusées depuis une même adresse en une minute (30), ou une file de jobs pleine.

Garantie · roles-read-review-write-dev · référencée · exécutée sur aff6caab7514 · portée vérifiée par son auteur (IA), pas relue Chaque route de la table de l'API du Studio demande un reviewer quand elle ne fait que lire (un GET, ou l'un des POST de lecture) et un dev sinon ; le test parcourt toute la table.

Limite · roles-fixed Les trois rôles sont fixes : pas de rôle sur mesure, pas de droit par salle, pas de dev en lecture seule. Les groupes d'un fournisseur ne donnent aucun droit.

Identifiants liés

• Gérer les membres, Invitations.
• Concepts : pans, baux, bail exclusif.
• ADR 0027 : les quatre politiques HTTP.

Modifier la source de cette page · Signaler une erreur