README: Reseed-Anleitung fuer bekannte Admin-/Portal-Creds
Eigene Unterrubrik unter "Erster Login": wie man auf bestehender DB (z.B. Staging nach Reset) datenerhaltend bekannte Zugangsdaten herstellt. Betont, dass der Seed nur Rollen + Admin-User upsertet (keine Kundendaten), das SEED_ADMIN_PASSWORD>=25-Zeichen-Verfahren + RUN_SEED, und dass Portal-Passwoerter danach im UI gesetzt werden. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@@ -229,6 +229,42 @@ Nach dem Seed sind folgende Zugangsdaten verfügbar:
|
||||
> **Wichtig:** Vor dem ersten Production-Deployment Secrets rotieren –
|
||||
> siehe [Production-Deployment](#production-deployment).
|
||||
|
||||
### Zugangsdaten auf bestehender DB neu setzen (Reseed)
|
||||
|
||||
Nützlich z.B. auf **Staging/Test nach einem DB-Reset**, wenn Admin-/Portal-
|
||||
Passwörter randomisiert sind und man wieder **bekannte** Zugangsdaten braucht
|
||||
(etwa für einen Pentester).
|
||||
|
||||
**Der Seed ist datenerhaltend:** Er `upsert`et nur die Rollen und den
|
||||
Admin-User (`admin@admin.com`) und synchronisiert die Rollen-Berechtigungen.
|
||||
**Kundendaten, Verträge, Bankkarten usw. werden NICHT angefasst** (das einzige
|
||||
`deleteMany` betrifft ausschließlich Rollen↔Permission-Zuordnungen). Ein
|
||||
erneuter Seed setzt also faktisch nur das Admin-Passwort neu.
|
||||
|
||||
**Admin-Passwort deterministisch neu setzen:**
|
||||
|
||||
```bash
|
||||
# 1) In der .env / docker-compose environment setzen:
|
||||
SEED_ADMIN_PASSWORD=<ein dir bekanntes Passwort, MIND. 25 Zeichen>
|
||||
RUN_SEED=true # erzwingt den Seed auch bei nicht-leerer DB
|
||||
|
||||
# 2) Container neu starten – der Entrypoint seedet erneut (upsert):
|
||||
docker compose up -d
|
||||
|
||||
# 3) Login: admin@admin.com / <SEED_ADMIN_PASSWORD>
|
||||
# 4) Danach RUN_SEED wieder auf false (sonst re-seedet jeder Restart – harmlos,
|
||||
# aber unnötig). SEED_ADMIN_PASSWORD kann gesetzt bleiben.
|
||||
```
|
||||
|
||||
> ⚠️ `SEED_ADMIN_PASSWORD` **muss ≥ 25 Zeichen** sein, sonst wird es ignoriert
|
||||
> (Passwort-Policy) und der Seed generiert wieder ein Zufallspasswort (→ Logs,
|
||||
> siehe oben).
|
||||
|
||||
**Portal-Login (Kunde):** Portal-Passwörter werden **nicht** vom Seed gesetzt.
|
||||
Nach dem Admin-Login lässt sich in der Kundenakte für einen (Test-)Kunden das
|
||||
Portal-Passwort im UI **anzeigen/neu setzen** – damit hat man wieder einen
|
||||
bekannten Portal-Zugang für Scoping-Tests.
|
||||
|
||||
## Production-Deployment
|
||||
|
||||
Vor dem öffentlichen Schalten der Instanz muss in der Production-`.env`:
|
||||
|
||||
Reference in New Issue
Block a user