Zum Inhalt

Login-/2FA-Probleme

Falsches Passwort mehrfach eingegeben

Der Login-Endpunkt ist rate-limitiert: 10 Anfragen pro Minute pro IP. Nach zu vielen Fehlversuchen in kurzer Zeit blockiert der Server weitere Versuche für kurze Zeit (HTTP 429) — das schützt gegen Brute-Force, kann sich für den betroffenen User aber wie ein Aussperren anfühlen. Fix: kurz warten, dann erneut versuchen; bei echtem Passwort-Verlust setzt ein Admin das Passwort zurück (Admin → Zugriff → Users).

2FA-Code wird nicht akzeptiert

  • Authenticator-App (TOTP): Zeit auf dem Smartphone und auf dem Server müssen synchron sein (TOTP ist zeitbasiert) — bei „Code ungültig" zuerst die Systemzeit auf beiden Seiten prüfen.
  • Sicherheitsschlüssel (WebAuthn): braucht eine aktiv konfigurierte Relying-Party-ID auf der Instanz — ist WebAuthn nicht eingerichtet, erscheint die Option gar nicht erst als wählbarer Faktor.

2FA-Lockout

Nach 5 Fehlversuchen bei der Code-Eingabe greift ein 30-Minuten-Lockout (HTTP 429 mit Retry-After-Header). Während des Lockouts hilft nur Warten oder ein Admin-Reset (siehe unten).

Komplett ausgesperrt (kein Authenticator, kein Sicherheitsschlüssel, keine Backup-Codes)

Das ist der Fall, für den es einen expliziten Admin-Weg gibt:

Admin → Zugriff → Users → betroffenen User → „2FA zurücksetzen"

Setzt die 2FA-Methode des Users komplett auf „keine" zurück (Audit-Eintrag wird geschrieben). Der User muss beim nächsten Login neu einrichten — und unterliegt dabei wieder jeder für ihn geltenden 2FA-Pflicht-Regel (Grace-Period greift erneut).

Voraussetzung: Es muss noch mindestens ein Super-Admin geben, der sich selbst einloggen kann, um den Reset durchzuführen. Ist niemand mehr zugriffsfähig (z. B. der einzige Admin-Account ist selbst ausgesperrt), bleibt nur der Server-seitige Notfall-Weg über den Admin-Bypass — siehe Admin-Zugriff & Split-Container.

Backup-Codes bei WebAuthn verloren

Backup-Codes sind bei der WebAuthn-Einrichtung Pflicht (kein Setup ohne sie) und werden einmalig angezeigt. Neue Codes erzeugen geht nur mit einem frischen Faktor-Nachweis (WebAuthn oder ein verbleibender Backup-Code) aus den letzten 5 Minuten — ein reines Login-Cookie reicht dafür bewusst nicht. Sind alle Codes aufgebraucht und der Schlüssel nicht verfügbar, bleibt nur der Admin-Reset oben.

2FA-Pflicht-Regel blockiert den Login

Greift eine 2FA-Pflicht-Regel (Admin → Zugriff → 2FA) für einen User, eine Rolle, eine Permission oder einen ganzen Tenant, und die Grace-Period ist abgelaufen, ohne dass der geforderte Faktor eingerichtet wurde, blockiert der Login komplett, bis der passende Faktor eingerichtet ist. Das ist kein Fehler, sondern die Regel greift wie konfiguriert — prüfe die Grace-Period und ob der User als Ausnahme eingetragen werden sollte (z. B. Service-Accounts ohne interaktiven Login).

Details: 2FA.

„Account deactivated"

Der User-Account wurde in der Verwaltung auf inaktiv gesetzt, statt gelöscht zu werden (üblicher Weg, weil Audit-Log-Verweise und Dashboard-Besitz erhalten bleiben). Fix: Admin → Zugriff → Users → User aktivieren.

Server-Zeit falsch

„Token not yet valid" oder „token expired" direkt nach dem Login deutet auf eine falsch eingestellte Serverzeit hin — JWTs und TOTP-Codes sind zeitkritisch. Fix: NTP auf dem Server einrichten (timedatectl prüfen/aktivieren), dann erneut versuchen.

Frontend zeigt nach Domain-Wechsel „Login fehlgeschlagen"

Nach einem Wechsel der Server-URL kann der Browser eine alte API-Basis-URL zwischengespeichert haben. Fix: Browser-Cache leeren, Hard-Reload — siehe UI-Probleme nach Update, derselbe Mechanismus.

Oberfläche lädt endlos neu, die Anmeldemaske erscheint nie

Läuft eine Sitzung ab, während ein Rest-Cookie im Browser zurückbleibt, konnte sich die Oberfläche vor v1.9.446 in einer Schleife aufhängen: sie schickte zur Anmeldung, hielt dich dort sofort wieder für angemeldet und lud das Dashboard erneut. Betroffen war immer nur der Browser, in dem der Zustand entstanden ist.

Behoben ab v1.9.446: Abmelden entfernt jetzt alle Merkmale, an denen die Oberfläche „angemeldet" erkennt, und kurz nach dem Abmelden gilt eine Sperre, die auch dann greift, wenn ein Cookie sich technisch nicht löschen lässt. Auf einer älteren Version hilft „Websitedaten löschen" für diese Adresse.

Dieselbe Wurzel hatte die Meldung „CSRF token missing or mismatched" beim Speichern nach dem Ein- oder Ausschalten des eigenen Admin-Containers: der Browser hielt zwei gleichnamige Sitzungs-Cookies aus altem und neuem Geltungsbereich. Ab v1.9.446 prüft der Server gegen beide und räumt den alten Satz mit ab.

Anmeldung antwortet mit „502" (nur v1.9.446)

Auf v1.9.446 konnte die Antwort auf Login, 2FA-Bestätigung und die stille Sitzungsverlängerung den Header-Puffer von nginx sprengen („upstream sent too big header") — niemand kam mehr hinein, laufende Sitzungen endeten nach 30 Minuten. Behoben in v1.9.447.

Wer auf v1.9.446 festhängt und nicht mehr an die Oberfläche kommt: auf dem Server docker compose pull && docker compose up -d — oder als Sofortmaßnahme im nginx-Container proxy_buffer_size 16k; setzen und nginx -s reload.

Anschluss