# 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/`).