Identidad, roles y alcance

Índice / Index · English

Traducción de docs/en/runtime/identity.md, que es el original. Si discrepan, manda el inglés.

Quién pregunta decide qué contiene la respuesta. Ésa es la regla sobre la que está construido el plano de control, y se aplica en la capa de servicio en vez de ruta por ruta, para que añadir una ruta no pueda ser una forma de olvidarla.

Las superficies de proveedor no entran aquí. Una integración se autentica con la credencial de su propia aplicación; nada de lo de abajo le aplica.

#Dos credenciales, y no son lo mismo

El token de operador actúa como administrador porque es la forma en que llega a existir la primera administradora — pero no es nadie, y todo lo que tiene que pertenecer a una persona lo rechaza. Registrar una aplicación o abrir una cuenta bancaria con él falla con owner_required salvo que diga de quién es.

No hay token de operador por defecto. La API se niega a arrancar sin uno de al menos dieciséis caracteres, porque un emulador que se distribuye con una contraseña conocida es un emulador sin contraseña.

La primera administradora se crea con POST /auth/bootstrap, que abre el token de operador. Alguien tiene que existir antes de que nadie pueda entrar a crear a nadie. npm run setup hace esa llamada como último paso, y npm run admin:create la hace por su cuenta; las dos van por la superficie HTTP y no por la base, así que ninguna puede crear una cuenta que la API habría rechazado.

#Los tres roles

Una persona lleva dos claves opcionales que la atan al libro mayor: walletKey (de dónde sale su dinero cuando paga con saldo) y merchantKey (con qué nombre se le paga). Una clave que no corresponde al rol se rechaza, porque es una clave que nada leería.

#Cómo se guarda una ruta

RolesGuard resuelve la credencial y luego compara el rol de quien llama con el @Roles(...) de la ruta. Ausente significa sólo administradores: el valor por defecto del plano de control tiene que ser el cerrado.

Un @Roles en el método pisa al del controlador, que es como el catálogo de bancos lo puede leer todo el mundo y escribirlo sólo una administradora — elegir dónde está tu cuenta significa ver la lista.

#Cómo se acotan las filas

Guardar una ruta dice quién puede llamarla. No dice nada sobre qué filas vuelven. Eso es una sola expresión por módulo, escrita una vez:

visible(caller): FilterQuery<Entity> {
  if (caller.role === 'admin') return {}
  if (!isPerson(caller)) return {}
  return { owner: caller.user.id }
}

Todo listado y toda lectura de una fila la intersecan. Dos consecuencias que vale la pena decir en voz alta:

• Un identificador que quien llama no puede ver responde 404, nunca 403. Un 403 sobre un identificador real confirma que es real, y eso convierte un código de error en una forma de enumerar los registros de otros.
• Un filtro puede estrechar el alcance y nunca ensancharlo. El alcance propio del endpoint se interseca con los filtros de quien llama; no se fusiona con ellos.

#Sesiones

Una sesión es una fila con un token en hash y una caducidad. Presentar una caducada la borra y responde como si nunca hubiera existido, lo que además evita que la tabla críe una cola de filas muertas que nadie barre. Cambiar la contraseña cierra todas las sesiones abiertas con la anterior.

La consola nunca tiene un token de sesión en el navegador: Nitro lo sella en una cookie, y cada petición reenviada se hace como la persona que entró. El token de operador es el respaldo y nada más. Ver la consola.

#Relacionado

• Autorización en el plano de control — dónde encaja esto en la arquitectura.
• El contrato de listados — qué puede pedirle alguien a un listado.
• Banco falso y contabilidad — qué nombran walletKey y merchantKey.