2.4 KiB
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.