Add SQLite web users, privileged account CLI and session editing claims
This commit is contained in:
Nico committed
1 parent
9fc5c1805c
commit
203e765992
18 files changed
+629
-60
No files matched your search
@@ -0,0 +1,40 @@
|
||||
# Benutzeranmeldung und Bearbeitungssperren – 2026-10-22
|
||||
|
||||
Umfang: SQLite-Benutzer mit gesalzenen scrypt-Passworthashes, getrennte
|
||||
Sitzungs-/Sperrendatenbank, Cookie-Anmeldung, CSRF-Schutz, Abmeldung,
|
||||
Konsolenbefehle create_user/delete_user/change_pw_user mit Privilegienprüfung.
|
||||
Alle Webbenutzer besitzen dieselben Rechte für alle Projekte. Keine Webverwaltung
|
||||
von Benutzern und keine Benutzerklassen. Bearer-Tokens bleiben für Maschinen.
|
||||
|
||||
Konsole: Linux-root/sudo oder Windows-elevierte Administratorberechtigung.
|
||||
Die Privilegienprüfung wurde mit simuliertem unprivilegiertem Aufrufer getestet;
|
||||
Benutzerbefehle mit temporärer Datenbank unter kontrollierter Testfreigabe geprüft.
|
||||
Keine realen Benutzerkonten wurden im Dienst-Workspace erzeugt.
|
||||
|
||||
Prüfungen:
|
||||
|
||||
- 57 lokale Tests bestanden: API, Benutzer/Sitzungen, menschliches Feedback,
|
||||
Dashboard, Worker und vcore-Übergabe.
|
||||
- Gleichzeitige SQLite-Übernahmen aus zwei Threads/Sitzungen: genau ein Gewinner.
|
||||
- HTTP: ohne Bearbeiten kein Feedback, fremde Sitzung weder Übernahme noch Antwort.
|
||||
- Abmeldung/Sitzungsablauf geben Sperren frei; Passwortwechsel/Löschung sperren
|
||||
alte Sitzungen. Falsches altes Passwort wird abgewiesen.
|
||||
- Alle Webbenutzer sehen alle Projekte/Betriebsaktionen. Fehlender CSRF-Header
|
||||
wird abgewiesen; fremder Login-Origin wird abgewiesen; Anmeldeversuche begrenzt.
|
||||
- Beide Feedbackausgänge bleiben möglich; unveränderte Budgets/Revision und
|
||||
idempotente Antworten erhalten. Maschinen-Bearer können menschliche Antworten
|
||||
nicht ohne Benutzersitzung bestätigen.
|
||||
- Echter Headless-Edge mit ausschließlich temporärem Testbenutzer: normale
|
||||
Anmeldung, UI-Projektsteuerung, Testanfrage zuerst schreibgeschützt, Bearbeiten
|
||||
aktiviert Formular, Navigation/Diagramme/Mobilansicht/Logout: PASS.
|
||||
Keine JS-Ausnahmen. Die erwartete 401 beim Prüfen einer noch nicht bestehenden
|
||||
Sitzung wird separat vom Browserfehlercheck ausgenommen.
|
||||
|
||||
Testdaten vor Ausführung: Trials 16.939.129.428 Bytes, kleine Fixtures/temporäre
|
||||
Dateien mit Reserve innerhalb des 20-GB-Budgets. Keine kostenpflichtigen
|
||||
LLM-Anfragen, keine Änderung an Analysebudgets oder der Designspezifikation.
|
||||
|
||||
Deployment: Benutzerdatei in root-/administratorgeschütztem Verzeichnis mit
|
||||
passenden Dienst-Leserechten betreiben; SQLite allein ersetzt keine OS-Dateirechte.
|
||||
Native Linux-Dateirechte/Chown und reale Windows-UAC/NTFS-ACLs sind beim Server-
|
||||
Deployment zu prüfen. Die API öffnet die Benutzerdatei ausschließlich read-only.
|
||||
@@ -0,0 +1,103 @@
|
||||
# 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.
|
||||
+15
-20
@@ -6,10 +6,12 @@ Die Betriebsübersicht wird durch die bestehende Übergabe-API ausgeliefert:
|
||||
.\.venv\Scripts\python.exe -m viano_bug_analysis.api serve --config config/api.local.toml
|
||||
```
|
||||
|
||||
Anschließend `http://127.0.0.1:8080/` öffnen und mit einem freigegebenen **API-Token**
|
||||
anmelden. Dies ist nicht der Gemini-Schlüssel. Der Token bleibt ausschließlich im
|
||||
Arbeitsspeicher des Tabs, nicht in Cookies, Local Storage oder URLs. Für entfernte
|
||||
Zugriffe HTTPS verwenden. Der Analyseworker läuft unabhängig davon wie unter
|
||||
Anschließend `http://127.0.0.1:8080/` öffnen und mit **Benutzername und Passwort**
|
||||
anmelden. Benutzer werden ausschließlich über privilegierte Konsolenbefehle
|
||||
angelegt, geändert und gelöscht, siehe [Benutzerverwaltung](user-accounts.md).
|
||||
Alle Webbenutzer haben dieselben Rechte für alle Projekte. Die unten beschriebenen
|
||||
Client-/Projektberechtigungen gelten weiterhin für externe API-Integrationen.
|
||||
Für entfernte Zugriffe HTTPS verwenden. Der Analyseworker läuft unabhängig davon wie unter
|
||||
[Analyseworker](analysis-worker.md) beschrieben. Das Öffnen der Übersicht löst
|
||||
keine Modellanfragen aus.
|
||||
|
||||
@@ -93,7 +95,8 @@ Fortsetzung angefordert werden; Budgets werden dabei nicht zurückgesetzt.
|
||||
|
||||
## Betriebssteuerung
|
||||
|
||||
Clients erhalten standardmäßig keine Betreiberrechte. Ein eigener Client mit
|
||||
Alle angemeldeten Webbenutzer können die Betriebssteuerung verwenden. Externe
|
||||
API-Clients erhalten standardmäßig keine Betreiberrechte. Ein eigener Client mit
|
||||
eigenem Token und `operator = true` in der API-Konfiguration erhält Aktionen für
|
||||
seine freigegebenen Projekte (Beispiel in `config/api.example.toml`). API nach einer
|
||||
Rechteänderung neu starten. Der Gemini-Schlüssel ist dafür nicht geeignet.
|
||||
@@ -140,24 +143,15 @@ Beobachtungen und „Test durchgeführt“ oder „Nicht durchführbar“. Die a
|
||||
Bestätigung ist erforderlich. Textdaten bleiben untrusted observations, keine
|
||||
auszuführenden Befehle. Diese erste Oberfläche nimmt Text, keine Dateianhänge an.
|
||||
|
||||
Clients brauchen `tester = true` oder Betreiberrechte und Projektzugriff, um eine
|
||||
Antwort zu bestätigen. Ein reiner Uploadclient erhält diese Rechte nicht automatisch.
|
||||
Beispiel eines separaten menschlichen Clients in der API-Konfiguration:
|
||||
|
||||
```toml
|
||||
[[clients]]
|
||||
id = "human-dev"
|
||||
token_env = "VBA_HUMAN_TOKEN"
|
||||
projects = ["viano-core"]
|
||||
tester = true
|
||||
```
|
||||
|
||||
Eigenen API-Token über diese Umgebungsvariable bereitstellen und API neu starten.
|
||||
Menschliche Antworten erfordern eine angemeldete Benutzersitzung und die exklusive
|
||||
Übernahme über **Bearbeiten**, siehe [Benutzeranmeldung](user-accounts.md).
|
||||
Es gibt keine gesonderten Testerrollen für Webbenutzer. Menschliche Zugänge
|
||||
ausschließlich mit `create_user` anlegen.
|
||||
Die bestätigende Identität und Zeit stammen vom Server, nicht aus frei editierbaren
|
||||
Formularfeldern. `GET /v1/test-requests` liefert ausschließlich freigegebene Projekte;
|
||||
`POST /v1/test-requests/{case-key}` bestätigt die konkrete Anfrage/Revision.
|
||||
Kollisionen, veraltete Anfragen und widersprüchliche Wiederholungen werden abgewiesen.
|
||||
Eine identische erneute Übermittlung desselben Clients bleibt ohne doppelte Wirkung.
|
||||
Eine identische erneute Übermittlung derselben Sitzung bleibt ohne doppelte Wirkung.
|
||||
|
||||
Eine bestätigte Antwort setzt `AWAITING_TEST_FEEDBACK` über den vorhandenen
|
||||
Coordinator auf `INVESTIGATING_HYPOTHESES` zurück. Revision, Budget und ursprüngliche
|
||||
@@ -185,7 +179,8 @@ LLM-Aufrufe aus.
|
||||
|
||||
## Datenschutz und Betrieb
|
||||
|
||||
`GET /v1/overview` benötigt einen Bearer-Token und liefert nur freigegebene Projekte.
|
||||
`GET /v1/overview` benötigt eine Benutzersitzung oder einen Maschinen-Bearer-Token.
|
||||
Webbenutzer sehen alle Projekte; Maschinenclients nur ihre freigegebenen Projekte.
|
||||
Prompts, vollständige Modellantworten, lokale Pfade und Zugangsdaten werden nicht
|
||||
an den Browser übergeben. Fallnamen werden als Text dargestellt. Die Seite lädt
|
||||
keine externen Fonts, Chartbibliotheken oder Analysedienste; Diagramme werden lokal
|
||||
|
||||
Reference in new issue
Block a user