Melo/LOGIN_STAND.md

Login-Analyse — Stand 2026-08-30 (Melo pausiert als Nebenprojekt)

Dieses Dokument sichert den Stand der Login-Bug-Analyse, bevor die Melo-Session geschlossen wird. Melo ist pausiert — das hier ist der Übergabe-Stand für den nächsten Anlauf.

Ausgangslage

Auftrag: Auto-Anmeldung + manuelle Baka-Anmeldung schlugen in der App fehl, obwohl die Server-Seite (baka_auth) laut Login-API-Tests für baka und tinker einwandfrei lief. Vorgabe: Server ist nicht das Problem, den Bug in der APP finden + fixen.

Ergebnis: Der Bug war NICHT in der App

Vollständige Prüfung des App-Codes ergab keinen Fehler:

• lib/services/baka_auth.dart, lib/services/gast_zugang.dart, lib/downloads/downloads_screen.dart, lib/downloads/youtube_search_screen.dart gelesen und nachvollzogen — Logik korrekt.
• Beide früher bereits gefundenen Login-Bugs sind längst im main-Branch gemergt und aktuell vorhanden:
  • Race Condition beim Auto-Login (_laufenderAutoLogin in baka_auth.dart) — Commit 609ca37edeb.
  • Manuelle Anmeldung schreibt das neue Passwort dauerhaft in NavidromeService zurück (_AnmeldeDialogState._anmelden()) — Commit 196303145a3.
• 39 relevante Unit-/Widget-Tests grün (baka_auth_test.dart, gast_zugang_test.dart, online_screen_test.dart).
• Echter Server-Endpoint https://baka-net.de/auth/login direkt per curl getestet (von diesem Server aus, der zugleich baka-net.de selbst ist) — Response-Format entspricht exakt dem, was der App-Code erwartet.
• DNS/TLS/Netzwerk/AndroidManifest: kein Problem gefunden.

Tatsächlicher Root Cause: Server-Bug (behoben)

/home/dustin/scripts/baka_auth.py (außerhalb des App-Repos, kein Git, Produktions-Auth-Server für baka-net.de/auth):

handle_login() verglich den Benutzernamen case-sensitiv (WHERE username=?), während jede andere Stelle im selben System (handle_whoami, nd_sync und baka_auth_sync in sso_sync.py) bewusst case-insensitiv vergleicht. Die App sendet die Schreibweise aus den gespeicherten Navidrome-Zugangsdaten — weicht die auch nur in Groß-/Kleinschreibung von der in baka_auth.db gespeicherten Schreibweise ab (z. B. durch den SSO-Sync von Authentik), meldet der Server "Falscher Benutzer", obwohl Konto und Passwort stimmen. Das erklärt exakt das Muster: Server-Tests mit exakt passender Schreibweise liefen grün, echte App-Logins (Auto- und manuelle Anmeldung) schlugen fehl.

Dieser Bug war bereits am 29.08. von einer früheren Session an Hermes gemeldet worden (siehe Session 618ae854-..., Deep-Investigation-Agent), aber nie umgesetzt — die Datei war bis zum Fix unverändert seit dem 20.08.

Fix (2026-08-30, mit Dustins Freigabe):

• handle_login() in baka_auth.py: Abfrage jetzt WHERE lower(username)=lower(?), konsistent mit dem Rest des Systems. Kanonischer Username aus der DB-Zeile wird danach für Session/last_login weiterverwendet (Indizes im Ergebnis-Tuple entsprechend angepasst).
• Backup vor der Änderung: /home/dustin/scripts/baka_auth.py.bak-20260830-221410.
• baka-auth.service neu gestartet (sudo systemctl restart baka-auth.service).
• Health-Check (/auth/health) und Login-Endpoint (mit unbekanntem User, liefert weiterhin korrekt "Falscher Benutzer") danach verifiziert.

Offener Punkt — als Nächstes prüfen

Die tatsächliche Wirkung des Fixes wurde noch NICHT mit echten Zugangsdaten auf einem echten Gerät bestätigt. Direkter Zugriff auf baka_auth.db (sqlite3) war in dieser Session durch den Berechtigungs-Classifier blockiert — die genaue gespeicherte Schreibweise für baka/tinker konnte daher nicht verifiziert werden. Der Fix selbst ist unabhängig davon korrekt (er wendet nur die im System bereits etablierte Konvention konsequent auch auf handle_login an), aber der praktische Beweis fehlt noch.

Nächster Schritt: Dustin, Baka oder Tinker sollten die App (Auto-Login beim Start, danach zur Sicherheit auch die manuelle Anmeldung im "YouTube"-Tab) einmal real testen. Falls es weiterhin fehlschlägt:

1. journalctl -u baka-auth.service -n 50 auf die konkrete Fehlermeldung prüfen.
2. Prüfen, ob eine Login-Sperre aktiv ist (5 Fehlversuche → 15 Min. Sperre, _login_erlaubt/_login_fehler in baka_auth.py) — die frühere Investigation vermutete, dass wiederholte Auto-Login-Versuche mit falscher Schreibweise genau das ausgelöst haben könnten.
3. Falls weiterhin ein Mismatch vermutet wird: sso_sync.py prüfen, ob baka_auth_sync() beim Anlegen eines neuen Users die vom Aufrufer übergebene Schreibweise 1:1 übernimmt (INSERT ... VALUES(?,...) mit dem Original-username-Parameter) — das ist die einzige Stelle, an der die in baka_auth.db gespeicherte Schreibweise ursprünglich entsteht.

Nebenbefund — geringes Risiko, nicht angefasst

Der Rate-Limit-Schlüssel für Login-Sperren (_login_erlaubt/_login_fehler in baka_auth.py) verwendet weiterhin die rohe, ungenormte Eingabe (body.get('username', '?')), nicht den kanonischen Namen. Bei unterschiedlicher Groß-/Kleinschreibung über mehrere Login-Versuche hinweg zählt das Rate-Limit dadurch potenziell inkonsistent (mehrere Zähler pro echtem Nutzer statt einem). Kein Sicherheitsproblem, nur Ungenauigkeit — absichtlich nicht mitgefixt, um die Änderung minimal zu halten.

Für die nächste Session

• Dieser Fix betrifft kein App-Repo — es gibt keinen App-Commit dazu, nur diese Datei hier als Doku. Die eigentliche Änderung liegt in /home/dustin/scripts/baka_auth.py auf dem Server (kein Git-Tracking).
• Hermes/Server-Seite sollte informiert werden, dass der am 29.08. gemeldete Bug jetzt behoben ist (falls das nicht schon anderweitig passiert ist).
• Volltext der ursprünglichen Root-Cause-Kette (Race Condition → Passwort-Rückschreibung → getrennte Passwort-Speicher Navidrome/baka_auth.db → Case-Sensitivity) steht im Transkript der Session 618ae854-0a01-4321-af16-a3fef7ecbc7e (~/.claude/projects/-home-dustin-mello-dev/).