- 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
6.3 KiB
6.3 KiB
API Authentication Guide
Übersicht
Die API verwendet zwei verschiedene Authentifizierungs-Mechanismen für unterschiedliche Zugriffslevel:
1. Admin-Routes (Session + CSRF)
- Zweck: Geschützte Admin-Funktionen (Deletion Log, Cleanup, Moderation, Statistics)
- Methode: HTTP Session (Cookie) + CSRF-Token
- Konfiguration:
.env→ADMIN_SESSION_SECRET(+ Admin-Benutzer in DB)
2. Management-Routes (UUID Token)
- Zweck: Self-Service Portal für Gruppen-Verwaltung
- Methode: UUID v4 Token in URL-Path
- Quelle: Automatisch generiert beim Upload, gespeichert in DB
1. Admin Authentication
Setup
- Session Secret setzen:
ADMIN_SESSION_SECRET=$(openssl rand -hex 32) - Backend starten – Migration legt Tabelle
admin_usersan. - Setup-Status prüfen:
curl -c cookies.txt http://localhost:5000/auth/setup/status - Initialen Admin anlegen (nur wenn
needsSetup=true):curl -X POST -H "Content-Type: application/json" \ -c cookies.txt -b cookies.txt \ -d '{"username":"admin","password":"SuperSicher123!"}' \ http://localhost:5000/auth/setup/initial-admin - Login für weitere Sessions:
curl -X POST -H "Content-Type: application/json" \ -c cookies.txt -b cookies.txt \ -d '{"username":"admin","password":"SuperSicher123!"}' \ http://localhost:5000/auth/login - CSRF Token abrufen (für mutierende Requests):
curl -b cookies.txt http://localhost:5000/auth/csrf-token
Verwendung
Alle /api/admin/*- und /api/system/*-Routen setzen voraus:
- Browser sendet automatisch das Session-Cookie (
sid). - Für POST/PUT/PATCH/DELETE muss der Header
X-CSRF-Tokengesetzt werden.
Beispiel:
CSRF=$(curl -sb cookies.txt http://localhost:5000/auth/csrf-token | jq -r '.csrfToken')
curl -X PATCH \
-H "Content-Type: application/json" \
-H "X-CSRF-Token: $CSRF" \
-b cookies.txt \
-d '{"approved":true}' \
http://localhost:5000/api/admin/groups/abc123/approve
Geschützte Endpoints (Auszug)
| Endpoint | Method | Beschreibung |
|---|---|---|
/api/admin/deletion-log |
GET | Deletion Log Einträge |
/api/admin/deletion-log/csv |
GET | Deletion Log als CSV |
/api/admin/cleanup/run |
POST | Cleanup manuell starten |
/api/admin/cleanup/status |
GET | Cleanup Status |
/api/admin/rate-limiter/stats |
GET | Rate-Limiter Statistiken |
/api/admin/groups |
GET | Alle Gruppen (Moderation) |
/api/admin/groups/:id/approve |
PATCH | Gruppe freigeben |
/api/admin/groups/:id |
DELETE | Gruppe löschen |
/api/system/migration/* |
POST | Migrationswerkzeuge |
Error Codes
| Status | Bedeutung |
|---|---|
401 |
Session fehlt oder ist abgelaufen |
403 |
CSRF ungültig oder Benutzer hat keine Admin-Rolle |
419 |
(optional) Session wurde invalidiert |
2. Management Authentication
Setup
Kein Setup nötig! Token werden automatisch generiert.
Funktionsweise
- Bei Upload wird automatisch ein UUID v4 Token generiert
- Token wird gespeichert in DB (Spalte:
management_token) - Token wird zurückgegeben in der Upload-Response
- Nutzer erhält Link wie:
https://example.com/manage/{token}
Verwendung
Token wird im URL-Path übergeben (nicht im Header):
# Token validieren und Daten laden
GET /api/manage/550e8400-e29b-41d4-a716-446655440000
# Bilder hochladen
POST /api/manage/550e8400-e29b-41d4-a716-446655440000/images
# Gruppe löschen
DELETE /api/manage/550e8400-e29b-41d4-a716-446655440000
Geschützte Endpoints
| Endpoint | Method | Beschreibung |
|---|---|---|
/api/manage/:token |
GET | Gruppen-Daten laden |
/api/manage/:token/consents |
PUT | Social Media Consents |
/api/manage/:token/metadata |
PUT | Metadaten bearbeiten |
/api/manage/:token/images |
POST | Bilder hinzufügen |
/api/manage/:token/images/:imageId |
DELETE | Bild löschen |
/api/manage/:token |
DELETE | Gruppe löschen |
Sicherheits-Features
- Token-Format Validierung: Nur gültige UUID v4 Tokens
- Rate Limiting: Schutz vor Brute-Force
- Audit Logging: Alle Aktionen werden geloggt
- DB-Check: Token muss in DB existieren
Error Codes
| Status | Bedeutung |
|---|---|
404 |
Token nicht gefunden oder Gruppe gelöscht |
429 |
Rate Limit überschritten |
Testing
Unit Tests
npm test -- tests/unit/auth.test.js
Integration Tests
# Admin Auth testen
npm test -- tests/api/admin-auth.test.js
# Alle API Tests
npm test
Manuelles Testen
- Login:
curl -c cookies.txt -X POST -H "Content-Type: application/json" \ -d '{"username":"admin","password":"Secret123"}' \ http://localhost:5000/auth/login - CSRF holen:
CSRF=$(curl -sb cookies.txt http://localhost:5000/auth/csrf-token | jq -r '.csrfToken') - Admin-Route aufrufen:
curl -b cookies.txt -H "X-CSRF-Token: $CSRF" http://localhost:5000/api/admin/deletion-log # → 200 OK - Ohne Session (z. B. Cookies löschen) → Request liefert
403 SESSION_REQUIRED.
Production Checklist
ADMIN_SESSION_SECRETsicher generieren (>= 32 Bytes random).envnicht in Git committen (bereits in.gitignore)- HTTPS verwenden (TLS/SSL) damit Cookies
Securegesetzt werden können - Session-Store auf persistentem Volume ablegen
- Rate Limiting & Audit Logs überwachen
- Admin-Benutzerverwaltung (On-/Offboarding) dokumentieren
Sicherheits-Hinweise
Session-Secret Rotation
- Wartungsfenster planen (alle Sessions werden invalidiert)
- Neuen
ADMIN_SESSION_SECRETgenerieren .envaktualisieren und Backend neu starten
Management-Token
- Token sind permanent gültig bis Gruppe gelöscht wird
- Bei Verdacht auf Leak: Gruppe löschen (löscht auch Token)
- Token-Format (UUID v4) macht Brute-Force unpraktisch
Best Practices
- Keine Admin-Secrets im Frontend oder in Repos committen
- Admin-Session-Cookies nur über HTTPS ausliefern
- Rate-Limiting für beide Auth-Typen aktiv halten
- Audit-Logs regelmäßig auf Anomalien prüfen
- Session-Store-Backups schützen (enthalten Benutzer-IDs)