PullMD Teil 11: Multi-User-Pivot – Einfach erklärt
Am Ende der letzten Geschichte stand ein Punkt ganz oben auf meiner Liste: das Tool soll mehrere Konten unterstützen können. Mit Login, Passwort, eigenen Bereichen. Das hatte ich gar nicht für diese Woche geplant.
Warum das plötzlich ganz oben stand
Der Aha-Moment kam nicht durch diesen einen Punkt. Sondern durch zwei weitere, die direkt darunter auf der Wunschliste standen.
Beide drehten sich darum, dass andere Leute ihr Chat-Programm direkt mit ihrer eigenen PullMD-Installation verbinden wollen. Dafür braucht es OAuth (ein Verfahren, bei dem man sich über einen anderen Dienst anmeldet, statt ein eigenes Passwort anzulegen). Und OAuth setzt zwingend voraus, dass es Benutzerkonten gibt. Kein Login-System, kein OAuth. Kein OAuth, kein Zusammenspiel mit den Chat-Diensten.
Es ging also gar nicht um eine Reihenfolge nach Wichtigkeit. Es ging darum, dass das eine ohne das andere technisch nicht funktioniert. Also fing ich an.
Der Plan: drei Modi
Der wichtigste Punkt: das Update darf niemandem etwas kaputt machen. Laut der GitHub-Statistik hatten über 300 Leute das Tool in den letzten zwei Wochen heruntergeladen. Wenn die einfach nur ein Update einspielen, sollen sie nicht plötzlich vor einem Login-Bildschirm stehen.
Deshalb gibt es jetzt drei Modi:
- Aus (Standard): alles läuft wie vorher. Kein Login, nichts zu konfigurieren. Wer nichts ändert, merkt nichts.
- Einzelnutzer: ein einziger Login, kein Selbst-Anmelden anderer. Für Leute, die ihr Tool nur für sich selbst betreiben.
- Mehrere Nutzer: mehrere Konten mit eigenen Passwörtern, für geteilte Installationen.
Wer nichts ändert, bekommt den Aus-Modus. Wer Login will, schreibt drei Zeilen in eine Konfigurationsdatei und startet neu. Alles Bisherige bleibt intakt: neue Tabellen kommen dazu, aber nichts Bestehendes geht kaputt.
Vier Tage, dreißig Änderungen
Die Liste der Änderungen zwischen alter und neuer Version sieht lang aus. Ist sie aber nicht: das meiste sind Tests und Dokumentation. Das eigentliche Login-System besteht aus einem Wächter, der bei jedem Zugriff prüft, wer da gerade unterwegs ist, und vier neuen Tabellen in der Datenbank für Konten, Sitzungen, Schlüssel und Abruf-Zuordnungen.
Passwörter werden mit einem modernen Verfahren namens Argon2id gespeichert. Das Besondere daran: es ist absichtlich langsam und speicherhungrig. Dadurch wird es extrem teuer, Passwörter durchzuprobieren. Die Einstellungen entsprechen der offiziellen Empfehlung der OWASP (einer internationalen Organisation für Web-Sicherheit). Und es gibt einen kleinen Trick gegen das Erraten von Kontonamen: meldet sich jemand mit einem Namen an, den es gar nicht gibt, tut der Dienst trotzdem so, als würde er ein Passwort prüfen. Sonst könnte ein Angreifer an der Antwortzeit ablesen, welche Konten existieren.
Sitzungen funktionieren über einen kleinen Keks im Browser, der sieben Tage hält und sich bei Nutzung verlängert. Darin steckt nur eine lange zufällige Zeichenfolge, keine persönlichen Daten.
Schlüssel für Programme: Wer PullMD mit anderen Programmen oder Skripten verbinden möchte, kann sich spezielle Schlüssel erstellen. Diese werden nie im Klartext in der Datenbank abgelegt. Nur ein Anfangsstück bleibt sichtbar, damit man in der Liste erkennt, welcher Schlüssel welcher ist.
Notfall-Werkzeug: Falls jemand sein Admin-Passwort vergisst, gibt es ein kleines Programm auf der Befehlszeile zum Zurücksetzen.
Das ganze System ist so gebaut, dass alle Login-Wege am selben Punkt ankommen. Ob jemand per Browser-Sitzung, per Schlüssel oder per altem Verfahren aus Version 1 hereinkommt: die eigentlichen Funktionen fragen nur noch “wer bist du?”, nicht “wie bist du reingekommen?”. Deshalb lässt sich OAuth als weiterer Weg später einfach dazubauen, ohne alles Bestehende anzufassen.
Sicherheits-Prüfung, öffentlich ins Repo gelegt
Vor der Veröffentlichung habe ich einen eigenen Sicherheits-Check gemacht: einen zweiten Claude-Agenten in der Rolle des Kritikers über den Code schauen lassen. Das Ergebnis: ein wirklich kritischer Fehler und zwei mittlere Probleme, alle drei noch vor der Freigabe behoben.
Der kritische Fehler: ein gerade erzeugter Schlüssel wurde in der Web-Adresse mitgeschickt. Das klingt harmlos, ist es aber nicht. Web-Adressen landen überall: im Browser-Verlauf, in Server-Protokollen, in Verweisen anderer Webseiten. Der Schlüssel hätte an Stellen auftauchen können, wo er nicht hin sollte. Behoben: der Schlüssel kommt jetzt über eine sichere Kurznachricht innerhalb der Sitzung.
Danach blieben noch sechs kleinere Punkte offen. Nicht dringend, aber wissenswert. Und jetzt der Teil, den ich anders gemacht habe als üblich: diese sechs Punkte habe ich öffentlich ins Repo gelegt, in einer Datei, die jeder finden und lesen kann. Statt die Punkte still zu beheben oder zu verstecken: Wer PullMD bei sich installiert, soll selbst entscheiden können, ob diese Punkte für die eigene Situation relevant sind.
Ein Ausrutscher in den Begleit-Notizen
Beim Schreiben der Begleit-Notizen zur neuen Version ist Claude eine interne Test-Adresse aus meinem Heimnetz reingerutscht. Eine Adresse, die in einem öffentlichen Text nichts zu suchen hatte. Innerhalb von Minuten korrigiert, kein großer Schaden.
Aber ein sauberes Beispiel dafür, dass Begleittexte genauso aufmerksam gelesen werden müssen wie der eigentliche Code. Ich hatte keine automatische Prüfung, die so etwas vorher abfängt. Steht auf der Liste.
Die neue Version bleibt absichtlich noch nicht der Standard
Für Software-Pakete gibt es oft ein “immer die aktuellste Version”-Etikett. Wer dieses Etikett verwendet, bekommt bei einem Update automatisch das Neueste.
Ich habe dieses Etikett bewusst noch nicht auf die neue Version umgestellt. Wer also automatisch aktualisiert, bekommt weiterhin die alte Version. Das neue Login-System taucht nicht über Nacht bei jemandem auf, der das Tool nur für sich allein betreiben wollte. Wer die neue Version explizit will, kann das einstellen. In zwei Wochen schaltet ein kleiner automatischer Helfer das Etikett um, aber nicht ohne meine Freigabe.
Ein Verlaufs-Bug und drei misslungene Layout-Versuche
In den letzten Stunden vor der Veröffentlichung gingen dann noch zwei Sachen schief.
Die erste: die Verlaufsliste war leer, obwohl der Speicher voll war. Alle Einträge lagen da, die Liste blieb trotzdem blank. Das Aktualisierungs-Skript hatte eine Verknüpfungs-Tabelle vergessen. Diese Tabelle hält fest, wer welchen Eintrag abgerufen hat, und genau daraus liest die Verlaufsansicht. Ein klassisches “hat bei mir funktioniert, weil meine Test-Daten sauber waren”-Problem: wer frisch aufsetzt, hat die Tabelle von Anfang an gefüllt. Wer von der alten Version hochzieht, eben nicht. Der Fix trägt die fehlenden Einträge nach und kann auch mehrmals laufen, ohne Schaden anzurichten.
Kleineres Drama, anderes Register: die Login-Seite. Ich habe dreimal am falschen Ende geschraubt. Erst mehr Abstand, dann eine Layout-Eigenschaft rein, dann wieder raus. Schuld war eine alte Regel aus einem ganz anderen Teil des Programms, die das ganze Login-Kärtchen verzog. Drei Fehlversuche für eine einzige Zeile.
Was ich eigentlich gelernt habe
Der Pivot war weniger Code als gedacht. Ein Login-System ist kein gigantischer Umbau: vier Tabellen und ein Wächter. Vier Tage von Version 1.2 bis Version 2.0, inklusive Sicherheits-Check, Tests und Dokumentation.
Die eigentliche Erkenntnis liegt woanders: die Sicherheits-Prüfung gehört mit ins Release. Wenn sechs kleinere Punkte offen bleiben, sollen die Leute, die das Tool bei sich installieren, das wissen. Nicht ich allein.
Was als Nächstes kommt
v2.0 ging am 2. Mai abends raus. Die logische nächste Stufe: das Zusammenspiel mit dem großen Chat-Dienst aktivieren. Denn dafür hatte ich ja eigentlich angefangen.
Was dann passiert ist, war eines der frustrierendsten Knobel-Erlebnisse seit langem. Und das Frustrierende war, dass ich lange am falschen Ende gesucht habe.
Teil 11 von 15 der PullMD Serie.
← PullMD Teil 10: Absichern, aber richtig | PullMD Teil 12: Spec-Compliant ist nicht genug →