Authentification de l'administrateur

SubLane utilise des identités locales globales et des abonnements à l'espace de travail avec des rôles de propriétaire, d'administrateur ou de membre. L'administrateur de premier plan possède l'espace de travail initial. Les sessions sont partagées entre les espaces de travail, tandis que les permissions sont étendues à l'espace de travail sélectionné. Voir accès des membres pour les permissions, les liens d'invitation et le cycle de vie du compte. API flux de travail cléLe cycle de vie du mot de passe et la commande de récupération locale sont décrits dans Contrôles d'équipe.

Configuration pour la première fois

Démarrer SubLane normalement et ouvrir l'interface utilisateur. Si la base de données n'a pas d'administrateur, /setup affiche une page de bienvenue expliquant le flux de configuration. Sélectionnez Démarrer la configuration à ouvrir /setup/admin. Saisissez d'abord le nom d'utilisateur et le mot de passe de l'administrateur, puis continuez à une étape séparée pour nommer le premier espace de travail. Soumettre la deuxième étape crée à la fois des enregistrements et vous signe. Aucune clé d'initialisation séparée n'est nécessaire.

L'assistant de configuration utilise /setup/adminLes deux itinéraires de configuration ne sont pas disponibles après l'initialisation : les visiteurs sign-out se connectent et les utilisateurs sign-in se rendent dans leur espace de travail approprié. Aucune identification d'état ou de compte à bord n'est stockée dans le stockage du navigateur.

Compléter l'installation localement avant d'ouvrir l'instance à d'autres utilisateurs. Jusqu'à ce que l'initialisation soit terminée, quiconque peut accéder à la page de configuration peut créer le premier administrateur. Compose le port hôte reste lié au loopback.

Les noms d'utilisateur utilisent 3–32 lettres ASCII, chiffres, soulignements ou tirets, commençant par une lettre ou un chiffre. Ils sont insensibles à la casse et stockés en minuscules. Les nouveaux mots de passe utilisent 8–20 caractères Unicode et ne sont pas triés.

L'administrateur, le premier espace de travail, l'adhésion à la propriété et la première session sont engagés dans une transaction. Un insert protégé garantit que les requêtes de configuration simultanée ne peuvent pas remplacer le premier administrateur. L'initialisation se ferme après le succès de la transaction, et le redémarrage du service ne la rouvre pas.

Les bases de données de développement héritées d'avant le schéma consolidé de pré-libération ne sont pas mises à jour automatiquement. Préservez l'ancien répertoire avant de lancer une nouvelle instance. setup.key d'une construction de développement antérieure est inutilisé par la nouvelle instance.

Supprimer ou remplacer la base de données n'est pas une procédure de récupération de mot de passe. reset-admin-password --password-stdin commande pour un administrateur existant, ou les flux de changement/reset authentifiés décrits dans Contrôles d'équipe.

Séances

• Login utilise un jeton de 256 bits opaque et aléatoire dans un HttpOnly, SameSite=Lax, path-root cookie.
• SQLite ne stocke que le Digest SHA-256 du jeton.
• Les sessions expirent après 12 heures, sans renouvellement coulissant.
• Au plus cinq sessions sont conservées par utilisateur. Une nouvelle connexion remplace seulement la plus ancienne session excédentaire de l'utilisateur.
• Déconnexion révoque la session en cours dans SQLite avant de signaler le succès et d'effacer le cookie.
• Les sessions survivent à un redémarrage normal du processus.
• Le navigateur stocke localement les préférences de thème et de langue, mais jamais les jetons de session.

L'interface utilisateur attend l'état de session du serveur avant d'afficher les pages protégées. Elle revérifie l'état sur focus et périodiquement, et retourne à l'ouverture de session lorsqu'un utilisateur protégé API demande de rapporter une session expirée. Déconnexion annule les requêtes en attente et efface les données en cache privé. La session d'arrière-plan vérifie également les données privées lorsque l'identifiant de l'utilisateur ou le rôle change.

Proxies inverses et HTTPS

Pour un déploiement de réseau, mettre fin HTTPS à votre proxy inverse et définir l'origine visible externe:

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

L'origine ne doit contenir que le schéma, l'hôte et le port optionnel. Les chemins, les identifiants, les paramètres de requête et les fragments sont rejetés. HTTPS origine publique permet des cookies sécurisés même lorsque la connexion proxy interne utilise HTTP.

Sans ce paramètre, les contrôles d'origine identique utilisent l'état Host et TLS réel de la requête. Les en-têtes d'hôte, de protocole et de pair transmis ne sont pas implicitement fiables. API par procuration pour le développement local.

Maintenez le moteur lié au loopback ou à un réseau privé derrière le proxy. Utilisez HTTPS pour l'accès au réseau; HTTP par défaut est pour le développement.

Demande de protection et limite des ressources

Tous les itinéraires de gestion /api/ exiger une session d'administrateur valide activée par défaut, sauf les paramètres d'authentification explicites. /api/keys et les /api/me/requests, /api/me/password, /api/me/limits et /api/me/usage Les membres peuvent lire leur propre état de session et signer, mais ne peuvent pas accéder aux API de gestion de l'administrateur. Les actifs de SPA statiques restent publics; rendre le paquet d'applications ne permet pas d'accéder aux données de gestion.

Les mutations nécessitent un en-tête d'origine exactement identique, rejettent les métadonnées de Fetch site croisé et acceptent JSON Seulement. Les organismes auth sont limités à 4 KiB et ont une date limite de lecture de cinq secondes.

La configuration, la connexion et l'inscription à l'invitation sont soumises à une limite de cinq heures par minute par pair de connexion et à une limite mondiale de soixante heures par minute. Responses L'état limiteur est limité à 1 024 pairs et est process-local, donc redémarrer réinitialise les compteurs. Derrière un proxy inversé, les clients partagent le budget de l' proxy jusqu'à ce que le support explicite de proxy-de confiance soit introduit.

La dérivation de mot de passe est limitée à deux opérations simultanées. Argon2id utilise 19 MiB, deux itérations, et une voie, suivant la OWASP référence de stockage de mots de passe. Ces limites ne sont pas une garantie de mémoire de processus total.

API

Configuration et connexion accepter username et password; le formulaire de configuration vérifie la confirmation du mot de passe avant de soumettre. JSON objet. Les réponses d'état authentifiées incluent l'identifiant utilisateur, le nom d'utilisateur et admin ou member Les réponses d'erreur contiennent des codes stables pour les messages frontend localisés.

Pour la ligne de commande HTTP clients, fournir l'en-tête d'origine correcte et JSON type de contenu explicitement. Ne mettez pas d'identifiants dans l'historique du shell ou les partagez dans les rapports de bogues.

Authentification à deux facteurs · Clés d’accès

/preferences

Ajoute un code de votre application d’authentification à la connexion par mot de passe. S’applique à votre compte dans tous les espaces. Connectez-vous sans mot de passe par empreinte, visage ou code PIN de l’appareil. Une clé d’accès vérifiée satisfait aussi la double authentification. Vous pouvez en ajouter 10 au maximum.

Conservez ces codes en lieu sûr. Chacun remplace une seule fois un code d’authentification. Ils ne seront plus affichés. Leur remplacement invalide tous les anciens codes.

Les clés d’accès nécessitent HTTPS ou localhost et un navigateur prenant en charge WebAuthn JSON.