PullMD Teil 6: 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 — also mit Login, Passwort, eigenen Bereichen.
Das hatte ich gar nicht für die nächsten Wochen geplant. Aber als ich abends vor der Liste saß, war klar: ich habe gar keine andere vernünftige Wahl.
Warum das plötzlich ganz oben stand
Der eigentliche Aha-Moment kam nicht durch diesen einen Punkt. Sondern durch zwei weitere, die direkt darunter standen.
Die beiden drehten sich darum, dass mein Tool mit großen Chat-Diensten zusammenarbeiten soll — also dass jemand sein Chat-Programm direkt mit seiner eigenen Installation meines Tools verbinden kann. Dafür braucht es aber zwingend ein Login-System. Ohne Login kein vernünftiges Zusammenspiel mit diesen Diensten.
Was ich für „wäre nett“ gehalten hatte, war eigentlich die Grundlage für zwei andere Dinge — das war mir vorher nicht klar.
Es ging also gar nicht um eine Reihenfolge nach Wichtigkeit. Es ging darum, dass das eine ohne das andere nicht geht. Also fing ich abends an.
Der Plan: drei verschiedene Modi
Der wichtigste Punkt: das Update darf niemandem etwas kaputt machen.
Es gibt inzwischen Leute, die mein Tool bei sich selbst installiert haben. Wenn die einfach nur ein Update einspielen, sollen sie nicht plötzlich vor einem Login-Bildschirm stehen, obwohl sie das gar nicht wollten.
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 Hobby-Hoster, die ihr Tool nur für sich selbst betreiben.
- Mehrere Nutzer — mehrere Konten mit eigenen Passwörtern, für geteilte Installationen.
Wer also nichts ändert, bekommt den Aus-Modus. Wer die neuen Funktionen will, schreibt drei Zeilen in eine Konfigurationsdatei und startet neu.
Vier Tage, dreißig kleine Verbesserungen
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 zwei Bausteinen: ein Wächter, der bei jedem Zugriff prüft, wer da gerade unterwegs ist. Und ein paar neue Tabellen in der Datenbank für die Konten und Sitzungen.
Passwörter: Werden mit einem modernen Verfahren verschlüsselt gespeichert (Argon2id, falls jemand den Namen kennen möchte). Mit Einstellungen, die strenger sind als die übliche Empfehlung der entsprechenden Sicherheits-Organisation.
Sitzungen: Ein kleiner Keks im Browser, der sieben Tage hält und sich bei Nutzung verlängert. Der Inhalt ist nur eine zufällige Buchstabenfolge — ohne irgendwelche persönlichen Daten.
API-Schlüssel: Wer mein Tool mit anderen Programmen verbinden möchte, kann sich Schlüssel erstellen. Diese werden nie im Klartext gespeichert — nur ein Anfangsstück bleibt sichtbar, damit man weiß, welcher Schlüssel welcher ist.
Notfall-Werkzeug: Falls jemand sein Admin-Passwort vergisst, gibt es ein kleines Befehlszeilen-Programm zum Zurücksetzen.
Das ganze System ist so gebaut, dass man später weitere Login-Wege einfach dazubauen kann — ohne das Bestehende anzufassen.
Eine eigene Sicherheits-Prüfung — und die habe ich öffentlich gemacht
Bevor ich die neue Version freigeschaltet habe, ließ ich einen Sicherheits-Helfer (also einen zweiten Claude-Agenten in einer kritischen Rolle) über meinen Code schauen.
Das Ergebnis: ein wirklich kritischer Fehler und zwei kleinere, die ich noch vor der Freigabe behoben habe.
Der kritische Fehler: ein gerade erzeugter API-Schlüssel wurde in der Web-Adresse mitgeschickt. Das klingt harmlos, ist aber problematisch — denn Web-Adressen werden überall mit-geloggt, im Browser-Verlauf, auf Servern, in Übersichten von Webseiten. Der Schlüssel hätte an Stellen landen können, wo er nicht hin sollte. Behoben: der Schlüssel kommt jetzt sicher in der Sitzung mit.
Danach blieben noch sechs „nicht dringend, aber gut zu wissen“-Punkte offen.
Und jetzt kommt 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 wegzubügeln oder zu verstecken: Wer mein Tool bei sich installiert, soll selbst entscheiden können, ob diese Punkte für ihn relevant sind. Transparenz vor Hochglanz.
Ein peinlicher Ausrutscher im Begleittext
Beim Schreiben der Begleit-Notizen zur neuen Version ist mir versehentlich eine interne Test-Adresse aus meinem Heimnetz reingerutscht. Eine Adresse, die in einem öffentlichen Text wirklich nichts zu suchen hatte.
Innerhalb von Minuten korrigiert. Aber peinlich.
Ich hatte keine automatische Prüfung, die so etwas vorher abfängt. Das wäre ein nützliches kleines Werkzeug — steht auf der Liste.
Kein großer Schaden. Aber ein sauberes Beispiel dafür, dass Begleittexte genauso aufmerksam gelesen werden müssen wie der eigentliche Code.
Die neue Version bleibt absichtlich noch nicht der Standard
Es gibt für Software-Pakete oft ein „immer-die-aktuellste“-Etikett. Wer dieses Etikett verwendet, bekommt automatisch das Neueste.
Bei mir habe ich dieses Etikett bewusst noch nicht auf die neue Version umgestellt. Wer also automatisch updatet, bekommt weiterhin die alte Version. Das neue Login-System taucht nicht plötzlich über Nacht bei jemandem auf, der mein Tool nur für sich allein nutzen wollte.
Wer die neue Version explizit will, kann das einfach einstellen. Und in zwei Wochen schaltet ein kleiner automatischer Helfer das Etikett um — aber nicht ohne dass ich das vorher freigebe.
Eine Selbstverpflichtung dagegen, voreilig zu empfehlen.
Ein Daten-Fehler und drei misslungene Layout-Versuche
Direkt nach dem Freischalten meldete sich der erste Admin: seine Verlaufs-Liste war leer, obwohl der Speicher voll war.
Mein Aktualisierungs-Skript hatte einen Verknüpfungs-Eintrag vergessen. Das klassische „hat bei mir funktioniert, weil meine Test-Daten sauber waren“-Problem. Behoben innerhalb derselben Stunde, mit einem Trick, der dafür sorgt, dass der Fix auch mehrmals laufen darf ohne Schaden anzurichten.
Kleinere Geschichte, anderes Thema: die Login-Seite sah dreimal schlecht aus, bevor ich den eigentlichen Grund fand — eine alte Layout-Regel aus einem ganz anderen Teil des Programms hat das ganze Login-Kärtchen verzogen. Drei Iterationen für eine Zeile Layout-Code. Keine Niederlage, aber auch nicht der eleganteste Weg.
Was ich eigentlich gelernt habe
Der Pivot war weniger Code als gedacht. Ein Login-System ist kein gigantischer Bau — es sind ein paar Tabellen und ein Wächter. Vier Tage, fertig.
Die eigentliche Erkenntnis liegt woanders: die Sicherheits-Prüfung mit veröffentlichen. Wenn sechs kleine Punkte offen bleiben, sollen die Leute, die mein Tool bei sich installieren, das wissen. Nicht ich allein.
Was als Nächstes kommt
Die neue Version ging am 02. 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 nicht ein Fehler von mir.
Teil 6 von 9 der PullMD Serie.
← PullMD Teil 5: Reddit-Tag und die ersten Issues | PullMD Teil 7: Spec-Compliant ist nicht genug →