Cette page n’est pas encore traduite : la version anglaise est affichée.
Qui prend les décisions
L’autorité est une abstraction, pas deux builds du SDK. Il n’existe ni SDK client ni SDK serveur. Il n’y a qu’un seul SDK, et ce qu’un appel donné a le droit de faire dépend de l’acteur qui l’effectue.
Un client maître n’est ni un client ni un serveur
La machine d’un joueur qui crée une salle (room) puis la fait tourner — un client maître (master-client) — détient les interfaces room-owner, et rien de plus. Ce n’est pas un serveur : il ne peut pas faire tout ce qu’un serveur fait. Ce n’est pas non plus un client ordinaire.
Un serveur dédié a la même forme, vue de l’autre côté : le même client sans le rendu, sans besoin d’un SDK séparé. Ce qui distingue les deux, c’est la confiance, pas la construction, et cette confiance passe par les droits accordés (grant).
Les interfaces suivent l’acteur, pas le côté
Un module n’expose pas « l’API client » et « l’API serveur ». Il expose ce que peut faire un room-owner, ce que peut faire un entry-validator, ce que peut faire un seller. Les pages de module regroupent leur interface de la même façon, par acteur.
Un rôle est à la fois le droit et la classification
Un rôle porte ce qu’un acteur peut faire, et c’est aussi la façon d’indiquer à qui une chose s’adresse. Il n’existe pas, à côté, de second axe fait de tags ou d’étiquettes.
C’est avec whoami que le code pose la question. Il renvoie l’acteur et les interfaces que cet acteur débloque à l’instant présent — pas une liste statique figée dans le binaire au moment du build.
L’endroit où le code s’exécute et l’acteur qu’il détient sont deux questions distinctes
| Question | Réponses |
|---|---|
| Où ce code s’exécute-t-il ? | une fonction cloud · un client de jeu · un hôte client maître ou serveur dédié |
| Quelle interface d’acteur détient-il ? | player · room-owner · entry-validator · seller · moderator · backend-service · … |
Disposés en grille, les deux axes sont indépendants et chaque case est atteignable :
| fonction cloud | client de jeu | hôte de salle | admin | |
|---|---|---|---|---|
player | ✓ | ✓ | ✓ | — |
room-owner | ✓ | ✓ — la machine d’un joueur, qui héberge | ✓ | — |
backend-service | ✓ | — | ✓ | ✓ |
La case en gras, c’est du code qui tourne sur un client et fait le travail d’un serveur. Elle a un nom — room-owner — et ce sont des droits accordés comme les autres.
Toutes les combinaisons sont permises. Une fonction cloud n’est pas privilégiée d’office, et un client n’est pas limité d’office : les droits viennent de ce qui est accordé, et ce qui est accordé est déclaré.
La révocation prend effet sans réémettre l’identifiant
Un identifiant (credential) désigne une identité. Il ne porte pas de liste de rôles. Les rôles sont résolus côté serveur, à chaque requête : le client ne détient donc jamais la preuve de ses propres permissions, et il ne lui reste rien de périmé à continuer de présenter après une révocation.
Révoquer un rôle prend donc effet sans réémettre l’identifiant ; voir Ce qu’apporte l’attribution d’un rôle.
La révocation n’est pas instantanée
Un rôle révoqué devient observable au plus tard à l’expiration du délai de fraîcheur déclaré pour le cache des droits. L’instantanéité n’est pas promise.
L’autorité se déclare, elle ne se déduit pas
- Un type de salle déclare son mode d’autorité, et il n’y a pas de valeur par défaut : soit la simulation de la plateforme exécute le tick, soit une autorité externe s’en charge — le serveur de jeu du studio, ou le client d’un joueur en tant que client maître. C’est l’objet de Qui exécute le tick.
- Le degré de confiance accordé à une autorité externe sur le résultat fait l’objet d’une déclaration distincte sur le type de salle : l’accepter, le vérifier avec un hook, ou ne pas l’accepter. Là non plus, pas de valeur par défaut.
- Quel identifiant se résout en quel rôle, et ce qu’est une clé hôte, c’est l’objet d’Access & Roles.