Esta página aún no está traducida: se muestra la versión en inglés.
Quién toma las decisiones
La autoridad es una abstracción, no dos compilaciones del SDK. No hay un SDK de cliente y otro de servidor. Hay un solo SDK, y lo que puede hacer cada llamada lo decide el actor que la hace.
Un cliente maestro no es ni cliente ni servidor
La máquina de un jugador (player) que crea una sala (room) y después la ejecuta — un cliente maestro — tiene las interfaces de room-owner y nada más. No es un servidor: no puede hacer todo lo que hace un servidor. Tampoco es un cliente común.
Un servidor dedicado es lo mismo visto desde el otro lado: el mismo cliente sin el renderizado, que no necesita un SDK aparte. Lo que separa a los dos es la confianza, no la construcción, y la confianza viaja en los permisos otorgados (grant).
Las interfaces dependen del actor, no del lado
Un módulo no expone “la API de cliente” y “la API de servidor”. Expone lo que puede hacer un room-owner, lo que puede hacer un entry-validator, lo que puede hacer un seller. Las páginas de módulo agrupan su interfaz de la misma manera: por actor.
Un rol es a la vez el derecho y la clasificación
Un rol define lo que un actor puede hacer, y también es la forma de decir a quién va dirigido algo. No existe un segundo eje de tags o etiquetas junto a él.
Con whoami el código lo pregunta. Devuelve el actor y las interfaces que ese actor desbloquea en este momento, no una lista estática grabada en el binario al compilar.
Dónde se ejecuta el código y qué actor tiene son preguntas distintas
| Pregunta | Respuestas |
|---|---|
| ¿Dónde se ejecuta este código? | una función en la nube · un cliente del juego · un host de cliente maestro o de servidor dedicado |
| ¿Qué interfaz de actor tiene? | player · room-owner · entry-validator · seller · moderator · backend-service · … |
Puestos en una cuadrícula, se ve que los dos ejes son independientes y que se puede llegar a cualquier celda:
| función en la nube | cliente del juego | host de la sala | administración | |
|---|---|---|---|---|
player | ✓ | ✓ | ✓ | — |
room-owner | ✓ | ✓ — la propia máquina de un jugador, como host | ✓ | — |
backend-service | ✓ | — | ✓ | ✓ |
La celda resaltada es código que se ejecuta en un cliente y hace el trabajo de un servidor. Tiene nombre — room-owner — y se otorga como cualquier otro permiso.
Cualquier combinación es válida. Una función en la nube no tiene privilegios por el solo hecho de serlo, y un cliente tampoco está limitado por serlo: los derechos vienen de los permisos otorgados, y esos permisos se declaran.
La revocación surte efecto sin volver a emitir la credencial
Una credencial nombra una identidad. No lleva una lista de roles. Los roles se resuelven del lado del servidor en cada solicitud, así que el cliente nunca tiene en su poder la prueba de sus propios permisos, y después de una revocación no le queda nada vencido que seguir presentando.
Por eso, revocar un rol surte efecto sin volver a emitir la credencial; consulta Qué implica otorgar un rol.
La revocación no es instantánea
Un rol revocado deja de valer, a más tardar, al cumplirse el límite de antigüedad declarado para la caché de derechos. No se promete que sea instantáneo.
Dónde se declara la autoridad, en lugar de deducirse
- Cada tipo de sala declara su modo de autoridad, y no hay valor predeterminado: el tick lo ejecuta la simulación de la plataforma o una autoridad externa — el servidor de juego del estudio, o el cliente de un jugador como cliente maestro. Eso se explica en Quién ejecuta el tick.
- Cuánto se confía en una autoridad externa respecto del resultado es otra declaración del tipo de sala: aceptarlo, verificarlo con un hook o no aceptarlo. Tampoco aquí hay valor predeterminado.
- Qué credencial se resuelve en qué rol, y qué es una clave de host (host key), está en Access & Roles.