«Compartiremos la contraseña»
La cuenta compartida no es una opción, sino lo que queda cuando la herramienta no ofrece nada más. Funciona bien durante unos meses, pero luego presenta su factura, siempre en el peor momento.
Tres consecuencias, todas mecánicas. Retirar el acceso a una sola persona obliga a cambiar la contraseña de TODOS, lo que implica volver a formar a todo un equipo el día de un despido o una baja, es decir, precisamente cuando menos se desea hacerlo. A continuación, nadie puede responder a la pregunta «¿quién modificó esta fila?», porque para la aplicación todos son la misma persona. Por último, no es posible otorgar un acceso parcial: quien solo consulta una cifra recibe exactamente los mismos permisos que quien emite facturas.
El reto, pues, no es la seguridad en sentido espectacular, nadie ataca una aplicación de quince personas, sino la irreversibilidad: una cuenta compartida no se deshace, se sustituye; y cuanto más se tarde, más costosa será esa sustitución.
- Retirar el acceso a una persona = cambiar la contraseña de todos.
- Ninguna respuesta posible a «¿quién hizo esto?»: una sola cuenta, una sola identidad.
- Sin acceso de solo lectura: consultar y modificar otorgan los mismos permisos.
Tres roles, y la frontera exacta entre ellos
En cuanto la aplicación requiere una autenticación, ya incorpora cuentas reales y separadas, además de tres roles. Son pocos, y así es intencionado: un sistema de permisos que no se entiende a primera vista es un sistema que se configura mal.
El administrador puede hacerlo todo y es el único que gestiona las cuentas: las crea, las desactiva y restablece contraseñas. El usuario trabaja dentro de la aplicación, crea, modifica y elimina datos, pero no ve la gestión de cuentas. El rol de solo lectura permite consultar: navega por todas partes, abre fichas, visualiza paneles de control y no puede escribir nada.
Lo relevante no es la lista, sino dónde se aplica la denegación. Para el rol de solo lectura, el bloqueo no consiste en ocultar un botón en pantalla: toda petición de escritura se rechaza antes de llegar a la ruta, mediante el middleware, con un código 403. Un botón oculto se puede sortear con el teclado o una herramienta de desarrollo; una denegación aplicada en capas superiores, no. Esa es la diferencia entre una interfaz que sugiere y una aplicación que hace valer sus reglas.
El rol viaja en la cookie de sesión firmada, lo que permite esta verificación sin consultar la base de datos en cada petición. Y un visitante sin sesión no accede a nada: las páginas lo redirigen a la pantalla de inicio de sesión recordando adónde iba, y las llamadas a la API reciben un 401.
- Administrador: todo, más la gestión de cuentas.
- Usuario: crea, modifica y elimina datos; sin acceso a la gestión de cuentas.
- Solo lectura: navega y consulta; toda escritura se rechaza con un 403 antes de la ruta.
- Sin sesión: 401 en la API, redirección al inicio de sesión en las páginas.
Abrir un acceso: un identificador, un rol y una contraseña provisional
Crear una cuenta requiere tres datos, ninguno de los cuales es una dirección de correo electrónico. El administrador introduce un identificador (de 2 a 31 caracteres: letras, dígitos, punto, guion y guion bajo), selecciona el rol y la aplicación genera ella misma una contraseña provisional.
Esta contraseña se muestra una única vez, en ese instante. No se puede recuperar después, ni en la lista de cuentas ni en ningún otro lugar: solo se conserva su huella digital. Si se pierde antes de ser transmitida, el administrador la regenera, una operación que tarda diez segundos. Además, la cuenta se marca como pendiente de cambio de contraseña: la persona debe elegir la suya propia en su primer acceso, de modo que el administrador nunca conoce la contraseña de sus compañeros.
No se envía ningún correo electrónico, y conviene saberlo antes de organizar el flujo: la aplicación carece por completo de servicio de envío. Corresponde al administrador transmitir el identificador y la contraseña provisional por sus propios medios. El corolario es más problemático en la práctica que la mera ausencia de correo: no hay opción automatizada de «contraseña olvidada». Quien la pierda deberá acudir al administrador, quien la restablecerá.
La primera cuenta, por su parte, se crea junto con la aplicación: identificador «admin», contraseña «admin», y el mismo cambio obligatorio en el primer acceso. Es una contraseña de arranque, no una contraseña definitiva, y la aplicación no permitirá conservarla.
- Identificador + rol: eso es todo lo que introduce el administrador.
- Contraseña provisional generada por la aplicación, mostrada UNA SOLA VEZ.
- Cambio obligatorio en el primer acceso, el administrador no la conoce después.
- Sin correo electrónico: la transmisión y los restablecimientos dependen del administrador.
Cerrar un acceso sin agujerear el historial
Una cuenta no se elimina, sino que se desactiva, y puede reactivarse. No es una facilidad técnica, sino la misma decisión que se toma con la papelera de datos: un registro eliminado definitivamente arrastra consigo todo lo que estaba vinculado a él, y solo nos damos cuenta meses después, al buscar algo que ya no existe.
Dos denegaciones están codificadas expresamente, y son precisamente las que evitan quedarse fuera. No es posible desactivar la propia cuenta, la acción más fácil de realizar por descuido al ordenar una lista. Tampoco se puede desactivar al último administrador activo: una aplicación sin administradores es una aplicación en la que nadie podrá volver a abrir un acceso, ni siquiera para sí mismo. La denegación es explícita, no se limita a fallar.
Un cese, por tanto, se resuelve con un solo gesto: sin tocar las contraseñas de los demás y sin borrar rastro alguno. Una sustitución requiere dos pasos: desactivar y crear.
- Desactivación reversible, no eliminación.
- Imposible desactivar la propia cuenta.
- Imposible desactivar al último administrador activo.
- Restablecimiento de contraseña por parte del administrador, en cualquier momento.
Qué no hace, y es mejor saberlo desde el principio
Los permisos son globales para toda la aplicación. Una cuenta lleva asociado un rol, y ese rol no se vincula a ninguna entidad, sección ni campo. Por tanto, no existe forma de expresar «este comercial solo ve a sus propios clientes», «esta persona accede a las intervenciones pero no a la facturación» o «este campo está oculto para los no directivos». Tres roles cubren bien la pregunta «¿consultar o modificar?», pero no abordan en absoluto la pregunta «¿qué parte?».
La aplicación registra CUÁNDO cambió un dato, nunca QUIÉN lo cambió. Cada registro incluye automáticamente su fecha de creación y su última fecha de modificación, pero ninguna columna almacena al autor. Las cuentas separadas responden, pues, a «¿quién puede entrar?», no a «¿quién escribió esta fila?», son dos preguntas distintas, y solo la primera se resuelve. Es la limitación más fácil de confundir con una funcionalidad incluida, porque tener cuentas nominativas da la sensación de contar con trazabilidad.
La autenticación se realiza únicamente con identificador y contraseña, y nada más. Sin inicio de sesión mediante cuentas de Google o Microsoft, sin SSO empresarial y sin segundo factor. Para un equipo que ya gestione sus identidades en otro lugar, esto supone una lista adicional de cuentas que mantener.
Estas cuatro limitaciones no son omisiones que haya que sortear: son los límites de lo que se entrega, y es más útil explicitarlas que dejar que las descubran. Todas comparten una solución común, que es precisamente la razón de ser del producto: el código de la aplicación es suyo. Se trata de un proyecto estándar de Next.js y Prisma, exportable como ZIP o desplegable en su propio repositorio: añadir una columna de autor, un aislamiento por equipos o una autenticación empresarial es un desarrollo habitual, sobre código que usted posee y que ningún proveedor puede negarle. Y si el aislamiento es estructural para su negocio, descríbalo desde el principio: es su texto el que define las entidades y sus relaciones.
- Permisos globales: sin aislamiento por entidad, sección ni campo.
- Fecha de modificación registrada, autor no registrado.
- Solo identificador y contraseña: sin SSO, sin inicio de sesión externo y sin segundo factor.
- Solución común: el código es suyo, y estas ampliaciones son desarrollos habituales.