Autenticación de administrador

SubLane utiliza identidades de inicio de sesión locales globales y membresías en espacios de trabajo con roles de propietario, administrador o miembro. El administrador de la primera ejecución es propietario del espacio de trabajo inicial. Las sesiones se comparten entre espacios de trabajo, mientras que los permisos se limitan al espacio de trabajo seleccionado. Ver acceso de miembros para permisos, enlaces de invitación y ciclo de vida de la cuenta. Las claves de puerta de enlace personales están disponibles a través de la API flujo de trabajo clave. El ciclo de vida de la contraseña y el comando de recuperación local se describen en controles del equipo.

Configuración por primera vez

Inicie SubLane normalmente y abra la interfaz de usuario. Si la base de datos no tiene administrador, /setup muestra una página de bienvenida que explica el flujo de configuración. Seleccionar Iniciar configuración abrir /setup/admin. Primero ingrese el nombre de usuario y la contraseña del administrador, luego continúe con un paso separado para nombrar el primer espacio de trabajo. Al enviar el segundo paso, se crean ambos registros y se inicia sesión. No se requiere una clave de inicialización por separado.

El asistente de configuración utiliza /setup/admin; al actualizarlo se regresa al paso de administrador. Ambas rutas de configuración no están disponibles después de la inicialización: los visitantes que han iniciado sesión van al inicio de sesión y los usuarios que han iniciado sesión van al espacio de trabajo correspondiente a su función. No se almacena ningún estado de incorporación ni credenciales de cuenta en el almacenamiento del navegador.

Complete la configuración localmente antes de abrir la instancia a otros usuarios. Hasta que se complete la inicialización, cualquiera que pueda acceder a la página de configuración puede crear el primer administrador. El escucha predeterminado y el puerto del host Compose permanecen vinculados al bucle invertido.

Los nombres de usuario utilizan entre 3 y 32 letras ASCII, números, guiones bajos o guiones, comenzando con una letra o un número. No distinguen entre mayúsculas y minúsculas y se almacenan en minúsculas. Las contraseñas nuevas utilizan entre 8 y 20 caracteres Unicode y no están recortadas. El inicio de sesión continúa aceptando contraseñas existentes hasta el límite anterior de 128 caracteres.

El administrador, el primer espacio de trabajo, la membresía de propiedad y la primera sesión se confirman en una transacción. Una inserción protegida garantiza que las solicitudes de configuración simultáneas no puedan reemplazar al primer administrador. La inicialización se cierra después de que la transacción se realiza correctamente y al reiniciar el servicio no se vuelve a abrir.

Las bases de datos de desarrollo heredadas anteriores al esquema de versión preliminar consolidada no se actualizan automáticamente. Conserve el directorio anterior antes de iniciar una nueva instancia. Las bases de datos que ya están en el esquema consolidado reciben la migración de invitación adicional. un sobrante setup.key de una compilación de desarrollo anterior no se utiliza en la nueva instancia.

Eliminar o reemplazar la base de datos no es un procedimiento de recuperación de contraseña. Usa el local reset-admin-password --password-stdin comando para un administrador existente, o los flujos de cambio/restablecimiento autenticados descritos en controles del equipo.

Sesiones

• El inicio de sesión utiliza un token opaco, criptográficamente aleatorio de 256 bits en una cookie de raíz de ruta HttpOnly, SameSite=Lax.
• SQLite almacena solo el resumen SHA-256 del token.
• Las sesiones caducan a las 12 horas, sin renovación deslizante.
• Se retienen como máximo cinco sesiones por usuario. Un nuevo inicio de sesión reemplaza solo la sesión excedente más antigua de ese usuario.
• Cerrar sesión revoca la sesión actual en SQLite antes de informar el éxito y borrar la cookie.
• Las sesiones sobreviven a un reinicio del proceso normal.
• El navegador almacena localmente las preferencias de tema e idioma, pero nunca tokens de sesión.

La interfaz de usuario espera el estado de la sesión del servidor antes de mostrar las páginas protegidas. Vuelve a verificar el estado en el foco y periódicamente, y regresa al inicio de sesión cuando una solicitud protegida API informa una sesión caducada. Cerrar sesión cancela las consultas pendientes y borra los datos privados almacenados en caché. Las comprobaciones de sesión en segundo plano también borran datos privados cuando cambia el ID de usuario o el rol.

Proxys inversos y HTTPS

Para una implementación de red, finalice HTTPS en su proxy inverso y configure el origen visible externamente:

SUBLANE_PUBLIC_URL=https://sublane.example.com ./bin/sublane

El origen debe contener únicamente el esquema, el host y el puerto opcional. Se rechazan rutas, credenciales, parámetros de consulta y fragmentos. Un origen público HTTPS habilita cookies seguras incluso cuando la conexión proxy interna utiliza HTTP.

Sin esta configuración, las comprobaciones del mismo origen utilizan el host de la solicitud y el estado TLS real. Los encabezados de host, protocolo y pares reenviados no son de confianza implícita. Vite preserva explícitamente el Host original en su proxy API para el desarrollo local.

Mantenga el backend vinculado al loopback o a una red privada detrás del proxy. Utilice HTTPS para acceder a la red; el valor predeterminado local HTTP es para desarrollo.

Solicitar protección y límites de recursos

Todas las rutas de gestión bajo /api/ requieren una sesión de administrador habilitada válida de forma predeterminada, excepto los puntos finales de autenticación explícita. Personal /api/keys y el explícito /api/me/requests, /api/me/password, /api/me/limits y /api/me/usage los puntos finales están protegidos por sesión para ambos roles y exigen la propiedad. Los miembros pueden leer su propio estado de sesión y cerrar sesión, pero no pueden acceder a las API de administración del administrador. Los activos estáticos de SPA siguen siendo públicos; renderizar el paquete de aplicaciones no otorga acceso a los datos de administración.

Las mutaciones requieren un encabezado de origen exactamente del mismo origen, rechazar metadatos de recuperación entre sitios y aceptar solo JSON. Los organismos de autenticación están limitados a 4 KiB y tienen una fecha límite de lectura de cinco segundos.

La configuración, el inicio de sesión y el registro de invitación comparten un límite de cinco intentos por minuto por par de conexión y un límite global de sesenta intentos por minuto. Responses incluye Reintentar después cuando se acelera. El estado del limitador está limitado a 1024 pares y es local del proceso, por lo que al reiniciar se restablecen los contadores. Detrás de un proxy inverso, los clientes comparten el presupuesto de pares del proxy hasta que se introduce soporte explícito de proxy confiable.

La derivación de contraseña está limitada a dos operaciones simultáneas. Argon2id utiliza 19 MiB, dos iteraciones y un carril, siguiendo el Línea base de almacenamiento de contraseñas de OWASP. Estos límites no son una garantía de memoria de proceso total.

API

Configurar e iniciar sesión aceptar username y password; el formulario de configuración verifica la confirmación de la contraseña antes de enviarla. El cierre de sesión acepta un objeto JSON vacío. Las respuestas del estado autenticado incluyen el ID de usuario persistente, el nombre de usuario y admin o member rol y nunca contenga tokens o hashes de contraseña. Las respuestas de error contienen códigos estables para mensajes de interfaz localizados.

Para clientes de línea de comandos HTTP, proporcione explícitamente el encabezado de origen correcto y el tipo de contenido JSON. No coloque credenciales en el historial del shell ni las comparta en informes de errores.

Autenticación de dos factores · Claves de acceso

/preferences

Añade un código de tu aplicación de autenticación al inicio de sesión con contraseña. Se aplica a tu cuenta en todos los espacios. Inicia sesión sin contraseña con tu huella, rostro o PIN del dispositivo. Una clave verificada también satisface la autenticación de dos factores. Puedes añadir hasta 10.

Guárdalos en un lugar seguro. Cada código sustituye una sola vez al del autenticador. No volverán a mostrarse. Al reemplazarlos, los anteriores dejarán de funcionar.

Las claves de acceso requieren HTTPS o localhost y un navegador compatible con WebAuthn JSON.