VianoBugAnalysis/docs/user-accounts.md

Benutzeranmeldung und exklusive Bearbeitung

Webbenutzer melden sich mit Benutzername und Passwort an. Alle Benutzer besitzen dieselben Rechte für alle Projekte. Es gibt weder Administrator-/Normalbenutzer- Klassen noch eine Benutzerverwaltung im Web. Bestehende Bearer-Tokens bleiben ausschließlich für externe API-Integrationen nutzbar und behalten deren bisherigen Zugriffsgrenzen. Fehlende Token-Umgebungsvariablen deaktivieren die jeweilige Integration; die Benutzeranmeldung benötigt keine Token-Zufallsgenerierung.

Konsolenverwaltung

Die Befehle erfordern unter Linux effektive root-Rechte (normalerweise sudo), unter Windows eine als Administrator gestartete Konsole. Sie benötigen keinen Gemini-Schlüssel und senden keine Modellanfrage.

sudo .venv/bin/python -m viano_bug_analysis.api create_user nico --config config/api.local.toml --service-group buganalysis
sudo .venv/bin/python -m viano_bug_analysis.api change_pw_user nico --config config/api.local.toml
sudo .venv/bin/python -m viano_bug_analysis.api delete_user nico --config config/api.local.toml

Ohne Passwortargumente erfolgt eine verdeckte Abfrage. Die gewünschten expliziten Argumentformen funktionieren ebenfalls:

create_user NAME PASSWORT --config DATEI
delete_user NAME --config DATEI
change_pw_user NAME ALTES_PASSWORT NEUES_PASSWORT --config DATEI

Explizite Passwortargumente können in Shellhistorie/Prozessargumenten auftauchen; für den normalen Betrieb die verdeckte Eingabe verwenden. Benutzernamen bestehen aus 1–64 ASCII-Buchstaben/Ziffern sowie Punkt, Unterstrich oder Bindestrich und beginnen mit einem Buchstaben oder einer Ziffer. Namen sind nicht case-sensitiv. Beim Passwortwechsel wird das alte Passwort geprüft. Passwortwechsel und Löschung entwerten bestehende Sitzungen und deren Bearbeitungssperren ohne API-Neustart.

Windows, in einer Administrator-PowerShell:

.\.venv\Scripts\python.exe -m viano_bug_analysis.api create_user nico --config config/api.local.toml

SQLite-Dateien und Betriebssystemrechte

Benutzer liegen standardmäßig in <workspace>/auth/users.sqlite3. Die API öffnet diese Datei ausschließlich schreibgeschützt. Gesalzene scrypt-Hashes ersetzen Klartextpasswörter. Sitzungen, Anmeldebegrenzung und Bearbeitungssperren liegen separat in <workspace>/runtime/web-sessions/sessions.sqlite3; Sitzungstokens werden dort nur als Hash gespeichert.

Produktionskonfiguration, Pfade relativ zur Konfigurationsdatei oder absolut:

[auth]
users_database = "/etc/viano-bug-analysis/users.sqlite3"
session_seconds = 3600

Die Benutzerdatei und ihr Verzeichnis gehören unter Linux root; CLI-Befehle setzen 0640 bzw. 0750. --service-group buganalysis erlaubt dem dedizierten Dienstkonto das Lesen, nicht die Benutzerverwaltung. Verzeichnisvorfahren dürfen nicht durch unvertrauenswürdige Benutzer austauschbar sein. Der Dienst benötigt Schreibzugriff auf seinen Workspace und die Sitzungsdatei. Unter Windows entsprechend geschützte NTFS-Verzeichnisse/ACLs verwenden: Administratoren verwalten die Benutzerdatei, das Dienstkonto liest sie. Die Konsolenbefehle prüfen auch dort die erhöhte Administratorberechtigung. Wer Programmcode oder Authentifizierungsdateien selbst ändern kann, liegt außerhalb der Web-Zugriffsgrenze; deshalb sind diese OS-Rechte Bestandteil der Servereinrichtung.

SQLite benötigt keinen MariaDB-Dienst. Für einen Umzug die Benutzerdatei und die Projekt-/Workspace-Daten sichern; die separate Sitzungsdatei kann bei gestoppter API bewusst verworfen werden, um alle Sitzungen und Sperren zu beenden.

Sitzungen und Bearbeiten

Die Anmeldung erzeugt ein HttpOnly-/SameSite-Strict-Cookie; unter HTTPS zusätzlich Secure. Entfernte Zugriffe über HTTPS betreiben. Mutationen benötigen den an die Sitzung gebundenen CSRF-Header. Die Oberfläche hält nur diesen CSRF-Wert im Arbeitsspeicher; Passwörter und Sitzungstokens werden nicht im Local Storage gespeichert. Sitzungen gelten standardmäßig absolut eine Stunde, konfigurierbar von 60 Sekunden bis 24 Stunden; regelmäßige Seitenaktualisierungen verlängern sie nicht endlos. Nach einem Neuladen kann eine gültige Sitzung weiterverwendet werden. Anmeldeversuche werden serverseitig zeitlich begrenzt.

Eine Testanfrage lässt sich zunächst nur ansehen. Erst Bearbeiten übernimmt die Anfrage atomar für die aktuelle Sitzung. Eine zweite Sitzung erhält API_TEST_CLAIMED und eine verständliche Meldung. Erst dann erscheinen Eingabefelder. Die Serverprüfung verlangt dieselbe Sperre auch beim Absenden; das Ausblenden von Feldern allein ist nicht die Zugriffskontrolle. Identische Wiederholungen bleiben idempotent, abweichende zweite Antworten werden zurückgewiesen.

Bearbeitung freigeben, Abmeldung oder Sitzungsablauf machen die Anfrage für andere Sitzungen verfügbar. Der Ablauf wird bei erneuter Übernahme anhand der serverseitigen Zeit geprüft; es wird kein Hintergrundtimer benötigt. Zwei Tabs derselben Sitzung gehören derselben Bearbeitung; zwei getrennte Sitzungen auch desselben Benutzers konkurrieren um die Sperre.

HTTP: POST /v1/auth/login, GET /v1/auth/session, POST /v1/auth/logout. Testübernahme/-freigabe: POST /v1/test-requests/{key}/claim mit {request_id,analysis_revision,action:"edit"|"release"}. Feedback bestätigt wie bisher die konkrete Anfrage und führt dieselbe Analyse-Revision fort. Bearer- Clients können keine menschliche Bearbeitungssperre oder Antwort übernehmen.