POST /auth/refresh wurde als CREATE / "Anmeldung erstellt" / CRITICAL / anonymous geloggt und sah damit wie eine anonyme Login-Flut aus. Es ist aber der regulaere Silent-Refresh des Frontend-Interceptors (Access-Token lebt nur im Speicher -> nach Reload/401 einmaliger Cookie-Refresh). - Neuer AuditAction-Wert TOKEN_REFRESH (Migration 20260818120000, idempotentes MODIFY COLUMN) - determineAction() mappt /auth/refresh -> TOKEN_REFRESH, Label "Sitzung verlaengert (Token erneuert)", Sensitivitaet explizit LOW (statt Default Authentication -> CRITICAL) - LOGIN/LOGOUT/LOGIN_FAILED bleiben unveraendert CRITICAL - Frontend: Filter-Option + dezente Badge-Farbe + Typ-Union - anonymous bewusst beibehalten (Endpoint ohne authenticate-Middleware) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
9 lines
413 B
SQL
9 lines
413 B
SQL
-- Neuer AuditAction-Wert TOKEN_REFRESH: trennt stille Access-Token-Refreshes
|
|
-- vom interaktiven Login-Rauschen (eigene Action + LOW-Sensitivität).
|
|
-- MODIFY COLUMN ist idempotent (setzt die Enum-Definition, mehrfach ausführbar).
|
|
ALTER TABLE `AuditLog`
|
|
MODIFY COLUMN `action` ENUM(
|
|
'CREATE','READ','UPDATE','DELETE','EXPORT','ANONYMIZE',
|
|
'LOGIN','LOGOUT','LOGIN_FAILED','TOKEN_REFRESH'
|
|
) NOT NULL;
|