Usuarios, Autenticación y Seguridad

Cuentas, autenticación y el modelo de seguridad, cómo Chinaski decide a quién se le permite hacer qué, cómo las sesiones se mantienen reales, y dónde se registra cada acción relevante para la seguridad. Las páginas siguen el viaje del operador: meter a la gente, acotarla, vigilar la huella.

En esta sección

• Usuarios y Roles, los dos roles (admin/editor), gestión de usuarios, suspensión y autorregistro.
• Autenticación, mecánica de sign-in, bloqueos, el modelo de sesión dual (cookie + registro del lado servidor) e invalidación de sesión.
• Contraseñas, reglas de contraseñas, expiración, resets y qué invalida un cambio de contraseña.
• SSO & OAuth, habilitar un proveedor de identidad real para equipos; cuentas creadas desde proveedores de identidad.
• Permisos, acotar editores por tipos de contenido e idiomas permitidos, más allá de los dos roles.
• Modelo de seguridad, las garantías a nivel de código: CSRF en todas partes, secrets con hash en reposo, sesiones firmadas y las reglas de confianza para headers de proxy.
• Registro de Auditoría, cada acción de seguridad registrada (logins, bloqueos, cambios de contenido), quién escribió qué, y la retención.
• Secretos, qué está cifrado y dónde (credenciales almacenadas, rotación de key de firma, el contrato de CHINASKI_SECRET del env).
• Fortalecimiento, las medidas a nivel de deployment: verificaciones de upload, honeypots, rate limiting, security log externo.
• Mi Cuenta, autoservicio: cambios de contraseña, perfil, preferencias de interfaz y "log out everywhere".

El modelo en un párrafo

La gente inicia sesión con usuario + contraseña (o un proveedor SSO cuando está configurado) y obtiene una sesión firmada y validada por el servidor; sus capacidades vienen luego de dos niveles, un rol (qué puede alcanzar) y restricciones por usuario (qué tipos de contenido e idiomas gestiona).Cada resultado de autenticación y cada mutación se registra, un audit trail más logs de auth/evento separados , con bloqueos, expiración y límites de tasa aplicados del lado servidorLos secrets (credenciales, keys) viven cifrados en reposo bajo una key derivada del CHINASKI_SECRET de la instancia, que es exactamente por qué ese archivo env importa tanto como los backups.

Lo que es deliberadamente simple

• Dos roles, luego refinamiento. No hay matriz de roles-por-ruta: editor más contenido-permitido/idiomas cubre las necesidades reales de una agencia; admin cubre el resto.
• Las sesiones son revocables. Suspender a un usuario, resetear una contraseña o "log out everywhere" termina las sesiones al instante, no en el próximo re-login. La expiración de contraseñas se aplica a nivel de aplicación.
• El audit trail es una tabla plana, lo bastante robusta para forenses del día a día, con una nota de durabilidad *best-effort* y un log JSON externo opcional para los eventos que no puedes permitirte perder.
• El autorregistro existe pero viene apagado, el registro, los resets de contraseña y Turnstile vienen todos deshabilitados/opcionales; habilitarlos es una elección deliberada.