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.
This commit is contained in:
Hermes (Server)
+111
@@ -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/`).
|
||||||
Reference in New Issue
Block a user