Login-Analyse gesichert: Bug war im Server (case-sensitiv), nicht in der App

Melo wird als Nebenprojekt pausiert — Übergabe-Doku LOGIN_STAND.md hält
den Analysestand fest: App-Code war bereits korrekt (beide früheren
Login-Fixes gemergt, 39 Tests grün), der eigentliche Bug lag in
handle_login() in /home/dustin/scripts/baka_auth.py (case-sensitiver
Username-Vergleich, inkonsistent zum Rest des Systems) und wurde dort
mit Dustins Freigabe behoben. Offener Punkt: echter Gerätetest steht
noch aus.

LOGIN_STAND.md

@@ -0,0 +1,111 @@
+# 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/`).