Sacamos el plugin de auth y escribimos nuestro propio RBAC
restoman1 min de lectura
El plugin de organizations de Better Auth modela una empresa plana. Un grupo gastronómico es una jerarquía, y los permisos tienen que heredar hacia abajo sin escalar nunca hacia arriba. Doblar el plugin habría costado más que reemplazarlo.
El plugin no estaba mal. Modela lo que la mayoría de los productos necesita: una empresa, sus miembros, y roles adentro. Plano.
Un grupo gastronómico no es plano. Hay un grupo, sus locales, los pisos de un local, y las estaciones de una cocina. Un encargado a nivel local debería heredar todo lo de abajo y nada de al lado. Eso no es una lista de roles: es un árbol con una regla de no-escalación.
La alternativa que descartamos
Dejar el plugin y modelar la jerarquía al lado — una segunda tabla mapeando miembros a scopes, consultada después de que el plugin contestara. Habría funcionado, y habría significado dos fuentes de verdad para una pregunta. Cada chequeo de permiso habría tenido que preguntarle a las dos y reconciliar, y la primera vez que no coincidieran tendríamos un bug de seguridad y no uno de renderizado.
Qué hicimos en cambio
Organizaciones, membresía y scopes en nuestro propio schema, con la herencia resuelta por permiso y no por rol. No "un encargado puede hacer X", sino "este permiso hereda hacia abajo desde el scope donde se otorgó".
El costo fue real: es más código y ahora es nuestro. Lo que lo hace la decisión correcta es que los permisos son la única parte de este sistema donde estar aproximadamente bien es lo mismo que estar mal.