# 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.