Administrator-Authentifizierung

SubLane Es wird verwendet globale Local-Login-Identitäten und Workspace-Mitgliedschaften mit Eigentümer-, Administrator- oder Mitgliedsrollen. Der First-Run-Administrator besitzt den ursprünglichen Workspace. Sitzungen werden über Workspaces hinweg geteilt, während Berechtigungen auf den ausgewählten Workspace ausgedehnt werden. Mitgliedszugang für Berechtigungen, Einladungslinks und Account-Lebenszyklus. Persönliche Gateway-Schlüssel sind über den separaten API Wichtiger WorkflowKennwort-Lebenszyklus und der lokale Wiederherstellungsbefehl werden beschrieben in Teamkontrollen.

Ersteinrichtung

Beginn SubLane normal und öffnen Sie die Benutzeroberfläche. Wenn die Datenbank keinen Administrator hat, /setup zeigt eine Begrüßungsseite, die den Setup-Flow erklärt. Starteinrichtung bis zum Öffnen /setup/adminZuerst geben Sie den Administrator-Benutzernamen und das Passwort ein, fahren dann mit einem separaten Schritt fort, um den ersten Arbeitsbereich zu benennen.

Der Setup-Wizard verwendet /setup/admin; Aktualisierung kehrt zum Administratorschritt zurück. Beide Setup-Routen sind nach der Initialisierung nicht verfügbar: Ausgeloggte Besucher gehen zum Login und angemeldete Benutzer gehen zu ihrem rollengerechten Arbeitsbereich. Im Browserspeicher werden kein Onboarding-Status oder keine Kontoanmeldeinformationen gespeichert.

Bis zum Abschluss der Initialisierung kann jeder, der auf die Setup-Seite zugreifen kann, den ersten Administrator erstellen. Compose Host-Port bleibt an Loopback gebunden.

Benutzernamen verwenden 3–32 ASCII-Buchstaben, Zahlen, Unterstriche oder Bindestriche, beginnend mit einem Buchstaben oder einer Zahl. Sie sind fallunempfindlich und in Kleinbuchstaben gespeichert. Neue Passwörter verwenden 8–20 Unicode-Zeichen und sind nicht beschnitten. Die Anmeldung akzeptiert weiterhin bestehende Passwörter bis zur vorherigen 128-Zeichen-Grenze.

Der Administrator, der erste Arbeitsbereich, die Eigentümermitgliedschaft und die erste Sitzung werden in einer Transaktion festgelegt. Ein geschützter Einsatz stellt sicher, dass gleichzeitige Einrichtungsanforderungen den ersten Administrator nicht ersetzen können. Die Initialisierung wird nach dem Erfolg der Transaktion geschlossen, und der Neustart des Dienstes öffnet ihn nicht erneut.

Legacy-Entwicklungsdatenbanken aus der Zeit vor dem konsolidierten Vorab-Schema werden nicht automatisch aktualisiert. Altes Verzeichnis vor dem Start einer neuen Instanz beibehalten. Bereits im konsolidierten Schema enthaltene Datenbanken erhalten die Migration der additiven Einladung. setup.key aus einem früheren Entwicklungs-Build von der neuen Instanz nicht verwendet wird.

Das Löschen oder Ersetzen der Datenbank ist kein Verfahren zur Passwortwiederherstellung. reset-admin-password --password-stdin Befehl für einen vorhandenen Administrator oder die authentifizierten Änderungs-/Reset-Flows, die in Teamkontrollen.

Sitzungen

• Login verwendet ein undurchsichtiges, kryptografisch zufälliges 256-Bit-Token in einem HttpOnly, SameSite=Lax, Pfad-Wurzel-Cookie.
• SQLite Speichert nur den SHA-256 Digest des Tokens.
• Die Sitzungen verfallen nach 12 Stunden ohne gleitende Erneuerung.
• Es werden höchstens fünf Sitzungen pro Benutzer beibehalten. Ein neues Login ersetzt nur die älteste überschüssige Sitzung dieses Benutzers.
• Logout hebt die aktuelle Sitzung in SQLite bevor Sie den Erfolg melden und das Cookie löschen.
• Sessions überleben einen normalen Prozessneustart.
• Der Browser speichert Themen- und Spracheinstellungen lokal, aber niemals Sitzungstoken.

Die Benutzeroberfläche wartet auf den Sitzungszustand des Servers, bevor sie geschützte Seiten anzeigt, überprüft den Status im Fokus und regelmäßig und kehrt zum Login zurück, wenn eine geschützte Seite API Request meldet eine abgelaufene Sitzung. Logout storniert ausstehende Abfragen und löscht private zwischengespeicherte Daten. Hintergrundsitzung überprüft auch das Löschen privater Daten, wenn sich die Benutzer-ID oder die Rolle ändert.

Reverse Proxies und HTTPS

Für eine Netzwerkbereitstellung enden HTTPS an Ihrem Reverse Proxy und legen Sie den äußerlich sichtbaren Ursprung fest:

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

Der Ursprung darf nur das Schema, den Host und den optionalen Port enthalten. HTTPS public origin ermöglicht Sichere Cookies, auch wenn die interne Proxy-Verbindung verwendet wird HTTP.

Ohne diese Einstellung verwenden die Same-Origin-Prüfungen den Host- und den tatsächlichen TLS-Status der Anforderung. Weitergeleitete Host-, Protokoll- und Peer-Header werden nicht implizit vertrauenswürdig. API Proxy für die lokale Entwicklung.

Halten Sie das Backend an Loopback oder ein privates Netzwerk hinter dem Proxy gebunden. HTTPS für den Netzwerkzugang; die lokale HTTP Default ist für die Entwicklung.

Anforderung von Schutz und Ressourcenlimits

Alle Managementrouten unter /api/ standardmäßig eine gültige aktivierte Administratorsitzung erfordern, mit Ausnahme der expliziten Authentifizierungsendpunkte. /api/keys und die explizite /api/me/requests, /api/me/password, /api/me/limits und /api/me/usage Endpunkte sind für beide Rollen sitzungsgeschützt und erzwingen das Eigentum. Mitglieder können ihren eigenen Sitzungsstatus lesen und sich abmelden, können jedoch nicht auf Administratorverwaltungs-APIs zugreifen. Statische SPA-Assets bleiben öffentlich; das Rendern des Anwendungspakets gewährt keinen Zugriff auf Verwaltungsdaten.

Mutationen erfordern einen exakten Origin-Header, lehnen Cross-Site-Fetch-Metadaten ab und akzeptieren JSON Nur Auth-Gremien sind auf 4 KiB begrenzt und haben eine Lesefrist von fünf Sekunden.

Einrichtung, Anmeldung und Einladungsregistrierung teilen sich ein Limit von fünf Versuchen pro Minute pro Verbindungs-Peer und ein globales Limit von sechzig Versuchen pro Minute. Responses Der Limiter-Zustand ist auf 1.024 Peers begrenzt und prozesslokal, so dass das Neustarten die Zähler zurücksetzt. Hinter einem Reverse-Proxy teilen sich Clients das Peer-Budget des Proxys, bis eine explizite Trusted-Proxy-Unterstützung eingeführt wird.

Die Passwortableitung ist auf zwei gleichzeitige Operationen beschränkt. Argon2id verwendet 19 MiB, zwei Iterationen und eine Spur, die dem folgenden folgt: OWASP-Passwortspeicherung Baseline. – Diese Limits stellen keine Garantie für den Gesamtprozessspeicher dar.

API

Setup und Login akzeptieren username und password; das Setup-Formular prüft die Passwortbestätigung vor dem Absenden. Logout akzeptiert eine leere JSON authentifizierte Zustandsantworten umfassen die persistente Benutzer-ID, den Benutzernamen und admin oder member Fehlerantworten enthalten stabile Codes für lokalisierte Frontend-Nachrichten.

für Kommandozeilen HTTP Kunden, liefern den korrekten Origin Header und JSON Inhaltstyp explizit: Legen Sie keine Anmeldeinformationen in die Shell-Historie oder teilen Sie sie in Fehlerberichten.

Zwei-Faktor-Authentifizierung · Passkeys

/preferences

Ergänzt die Passwortanmeldung um einen Code Ihrer Authenticator-App. Gilt für Ihr Konto in allen Arbeitsbereichen. Melden Sie sich per Fingerabdruck, Gesicht oder Geräte-PIN ohne Passwort an. Ein verifizierter Passkey erfüllt auch die Zwei-Faktor-Anforderung. Bis zu 10 sind möglich.

Bewahren Sie diese Codes sicher auf. Jeder ersetzt einmal einen Authenticator-Code. Sie werden nicht erneut angezeigt. Beim Ersetzen werden alle bisherigen Codes ungültig.

Passkeys erfordern HTTPS oder localhost und einen Browser mit WebAuthn-JSON-Unterstützung.