matthias.lotz
6332b82c6a
- replace bearer auth with session+CSRF flow and add admin user directory - update frontend moderation flow, force password change gate, and new CLI - refresh changelog/docs/feature plan + ensure swagger dev experience
77 lines
4.5 KiB
Markdown
77 lines
4.5 KiB
Markdown
# Feature Testplan: Admin-Session-Sicherheit
|
||
|
||
## Ziel
|
||
Sicherstellen, dass die neue serverseitige Admin-Authentifizierung (Session + CSRF) korrekt funktioniert, keine Secrets mehr im Frontend landen und bestehende Upload-/Management-Flows weiterhin laufen.
|
||
|
||
## Voraussetzungen
|
||
- `ADMIN_SESSION_SECRET` ist gesetzt – bei Dev in `docker/dev/backend/config/.env`, bei Prod in `docker/prod/backend/.env`. Wert per `openssl rand -hex 32` generieren.
|
||
- Docker-Stack läuft (`./dev.sh` bzw. `docker compose -f docker/dev/docker-compose.yml up -d` für Dev oder `docker compose -f docker/prod/docker-compose.yml up -d` für Prod).
|
||
- Browser-Cookies gelöscht bzw. neue Session (Inkognito) verwenden.
|
||
- `curl` und `jq` lokal verfügbar (CLI-Aufrufe), Build/Tests laufen innerhalb der Docker-Container.
|
||
|
||
## Testumgebungen
|
||
| Umgebung | Zweck |
|
||
|----------|-------|
|
||
| `docker/dev` (localhost) | Haupt-Testumgebung, schnelle Iteration |
|
||
| Backend-Jest Tests | Regression für API-/Auth-Layer |
|
||
| Frontend Build (`docker compose exec frontend-dev npm run build`) | Sicherstellen, dass keine Secrets im Bundle landen |
|
||
|
||
## Testfälle
|
||
|
||
### 1. Initiales Admin-Setup
|
||
1. `curl -c cookies.txt http://localhost:5001/auth/setup/status` → `needsSetup` prüfen.
|
||
2. Falls `true`: `curl -X POST -H "Content-Type: application/json" -c cookies.txt -b cookies.txt \
|
||
-d '{"username":"admin","password":"SuperSicher123"}' \
|
||
http://localhost:5001/auth/setup/initial-admin` → `success: true`, Cookie gesetzt.
|
||
3. `curl -b cookies.txt http://localhost:5001/auth/setup/status` → `needsSetup:false`, `hasSession:true`.
|
||
4. `curl -b cookies.txt http://localhost:5001/auth/logout` → 204, Cookie weg.
|
||
|
||
### 2. Login & CSRF (Backend-Sicht)
|
||
1. `curl -X POST -H "Content-Type: application/json" -c cookies.txt -b cookies.txt \
|
||
-d '{"username":"admin","password":"SuperSicher123"}' http://localhost:5001/auth/login`.
|
||
2. `CSRF=$(curl -sb cookies.txt http://localhost:5001/auth/csrf-token | jq -r '.csrfToken')`.
|
||
3. `curl -b cookies.txt -H "X-CSRF-Token: $CSRF" http://localhost:5001/api/admin/groups` → 200.
|
||
4. Fehlerfälle prüfen:
|
||
- Ohne Cookie → 403 `{ reason: 'SESSION_REQUIRED' }`.
|
||
- Mit Cookie aber ohne Token → 403 `{ reason: 'CSRF_INVALID' }`.
|
||
- Mit falschem Token → 403 `{ reason: 'CSRF_INVALID' }`.
|
||
|
||
### 3. Moderations-UI (Frontend)
|
||
1. Browser auf `http://localhost:3000/moderation` → Login oder Setup-Wizard erscheint.
|
||
2. Wizard ausfüllen (nur beim ersten Start).
|
||
3. Normales Login durchführen (korrekte & falsche Credentials testen).
|
||
4. Nach Login folgende Aktionen validieren (Network-Tab kontrollieren: Requests senden Cookies + `X-CSRF-Token`):
|
||
- Gruppenliste lädt.
|
||
- Gruppe approve/reject.
|
||
- Cleanup-Preview/-Trigger (falls Daten vorhanden).
|
||
- Social-Media-Einstellungen laden/speichern.
|
||
5. Logout in der UI → Redirect zum Login, erneutes Laden zeigt Login.
|
||
6. Browser-Refresh nach Logout → kein Zugriff auf Admin-Daten (sollte Login anzeigen).
|
||
|
||
### 4. Regression Upload & Management
|
||
1. Normales Upload-Formular durchspielen (`/`): Gruppe hochladen.
|
||
2. Management-Link (`/manage/:token`) öffnen, Consents ändern, Bilder verwalten.
|
||
3. Sicherstellen, dass neue Session-Mechanik nichts davon beeinflusst.
|
||
|
||
### 5. Öffentliche APIs
|
||
1. `curl http://localhost:5001/api/social-media/platforms` → weiterhin öffentlich verfügbar.
|
||
2. Slideshow & Gruppenübersicht im Frontend testen (`/slideshow`, `/groups`).
|
||
|
||
### 6. Bundle-/Secret-Prüfung
|
||
1. Dev-Stack: `docker compose -f docker/dev/docker-compose.yml exec frontend-dev npm run build` (Prod analog mit `docker/prod`).
|
||
2. `docker compose -f docker/dev/docker-compose.yml exec frontend-dev sh -c "grep -R 'ADMIN' build/"` → keine geheimen Variablen (nur Dokumentationsstrings erlaubt).
|
||
3. Falls doch Treffer: Build abbrechen und Ursache analysieren.
|
||
|
||
### 7. Automatisierte Tests
|
||
1. Backend: `docker compose -f docker/dev/docker-compose.yml exec backend-dev npm test` (neue Auth-Tests müssen grün sein).
|
||
2. Optional: `docker compose -f docker/dev/docker-compose.yml exec frontend-dev npm test` oder vorhandene E2E-Suite per Container laufen lassen.
|
||
|
||
### 8. CI/Monitoring Checks
|
||
- Pipeline-Schritt hinzunehmen, der `curl`-Smoke-Test (Login + `GET /api/admin/groups`) fährt.
|
||
- Optionaler Script-Check, der das Frontend-Bundle auf Secrets scannt.
|
||
|
||
## Testabschluss
|
||
- Alle oben genannten Schritte erfolgreich? → Feature gilt als verifiziert.
|
||
- Offene Findings dokumentieren in `FeatureRequests/FEATURE_PLAN-security.md` (Status + Follow-up).
|
||
- Nach Freigabe: Reviewer informieren, Deploy-Plan (z. B. neue Session-Secret-Verteilung) abstimmen.
|