104 lines
5.4 KiB
Markdown
104 lines
5.4 KiB
Markdown
# 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.
|
||
|
||
```bash
|
||
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:
|
||
|
||
```text
|
||
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:
|
||
|
||
```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:
|
||
|
||
```toml
|
||
[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.
|