diff --git a/LOGIN_STAND.md b/LOGIN_STAND.md new file mode 100644 index 0000000..4355961 --- /dev/null +++ b/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/`).