Document bootstrap seed script and admin password hash

2026-06-14 07:47:55 +00:00
parent 8b31dfc7ca
commit 7956d03629
3 changed files with 102 additions and 34 deletions
@@ -23,3 +23,5 @@
 - [018 - Repository-Schicht und System-Overview-Endpunkt](018-repository-schicht-system-overview.md)

 - [019 - Bootstrap-Admin und erste Seed-Daten](019-bootstrap-admin-und-erste-seed-daten.md)
+
+- [020 - Bootstrap-Seed-Script und Admin-Passwort](020-bootstrap-seed-script-und-admin-passwort.md)
@@ -9,44 +9,25 @@ Für RUVNOX Tactical wurden erste Seed-Daten direkt in PostgreSQL angelegt.
 - Admin-Benutzer: admin
 - Anzeigename: RUVNOX Admin
 - Rolle: admin
- Passwort-Hash: NULL
 - Einsatzraum: HQ
 - Einsatzraumname: RUVNOX Lagezentrum
 - Klassifizierung: internal
 - Mitgliedschaft: admin als lead im Raum HQ
 - Audit-Event: bootstrap.seed_completed

-## Ergebnis
+## Hinweis

-Der öffentliche Overview-Endpunkt liefert jetzt echte Werte:
+Der Schritt 019 hat zunächst den fachlichen Admin-Datensatz, den HQ-Raum und das Audit-Event angelegt.

-users.total = 1
-users.active = 1
-operationRooms.total = 1
-operationRooms.active = 1
-auditEvents = 1
+Der Overview-Endpunkt zeigte danach echte Werte:

-## Wichtiger Hinweis
+- users.total = 1
+- users.active = 1
+- operationRooms.total = 1
+- operationRooms.active = 1
+- auditEvents = 1

-Der Admin-Datensatz ist aktuell noch kein echter Login-Account.
-
-password_hash bleibt bewusst NULL, weil Auth/Login noch nicht implementiert ist.
-
-## Verifikation
-
-Benutzer:
-
-select username, display_name, role, is_active from app_users order by username;
-
-Einsatzräume:
-
-select code, name, classification, is_active from operation_rooms order by code;
-
-Audit:
-
-select event_type, entity_type, created_at from audit_events order by created_at desc limit 5;
-
-API:
+## API-Prüfung

 curl -fsS https://tactical.ruvnox.de/api/v1/system/overview

@@ -57,9 +38,3 @@ curl -fsS https://tactical.ruvnox.de/api/v1/system/overview
 - Admin als lead eingetragen
 - Audit-Event angelegt
 - Overview-Endpunkt geprüft
- Keine Server-Code-Änderung
- Keine Deploy-Code-Änderung
-
-## Nächster Abschnitt
-
-Empfohlen: Seed-Daten als kleines versioniertes Deploy-Script speichern oder direkt Auth-Grundlage beginnen.
@@ -0,0 +1,91 @@
+# 020 - Bootstrap-Seed-Script und Admin-Passwort
+
+## Ziel
+
+Die Bootstrap-Daten wurden reproduzierbar gemacht. Dafür wurde ein versioniertes Seed-Script im tactical-deploy Repository angelegt.
+
+Zusätzlich wird für den Admin-Datensatz jetzt lokal ein Passwort abgefragt und als PBKDF2-SHA256-Hash in PostgreSQL gespeichert.
+
+## Script
+
+Pfad:
+
+/opt/ruvnox/tactical/deploy-repo/scripts/seed-bootstrap-data.sh
+
+## Verhalten
+
+Das Script:
+
+1. lädt /opt/ruvnox/tactical/config/server.env
+2. fragt lokal ein Bootstrap-Admin-Passwort ab
+3. verlangt mindestens 12 Zeichen
+4. bestätigt das Passwort durch zweite Eingabe
+5. erzeugt einen PBKDF2-SHA256-Hash
+6. setzt app_users.password_hash für username admin
+7. stellt den HQ-Einsatzraum sicher
+8. stellt die lead-Mitgliedschaft des Admins in HQ sicher
+9. stellt ein Bootstrap-Audit-Event sicher
+
+## Wichtig
+
+Das Passwort wird nicht im Chat eingegeben.
+
+Das Passwort wird nicht im Git gespeichert.
+
+In der Datenbank liegt nur ein Hash im Feld password_hash.
+
+## Hash-Format
+
+Format:
+
+pbkdf2_sha256$iterations$salt_base64$hash_base64
+
+Aktuelle Iterationen:
+
+310000
+
+## Betroffene Tabellen
+
+- app_users
+- operation_rooms
+- operation_room_members
+- audit_events
+
+## Verifikation
+
+Admin-Passwort-Hash gesetzt:
+
+select username, password_hash is not null as has_password_hash from app_users where username = 'admin';
+
+Erwartung:
+
+has_password_hash = true
+
+## API-Verifikation
+
+curl -fsS https://tactical.ruvnox.de/api/v1/system/overview
+
+Erwartete Werte:
+
+- users.total = 1
+- users.active = 1
+- operationRooms.total = 1
+- operationRooms.active = 1
+- auditEvents >= 1
+
+## Sicherheitshinweis
+
+Der Admin hat jetzt einen Passwort-Hash in der Datenbank.
+
+Ein echter Login ist damit aber noch nicht aktiv, weil Login-Endpunkt, Passwortprüfung, Token-Erzeugung und Session-Verwaltung noch nicht implementiert sind.
+
+## Nächster Abschnitt
+
+Als nächstes folgt die Auth-Grundlage:
+
+- Passwort-Hash-Verifikation im Server
+- Login-DTOs
+- Login-Route
+- Session-/Token-Erzeugung
+- auth_sessions nutzen
+- System-Endpunkte schützen