Das Verzeichnis scripts/ wurde beim Bauen nie in die Laufzeitstufe
uebernommen. Der in der Anleitung dokumentierte Befehl
docker compose exec app node scripts/totp-geheimnis.mjs ...
endete deshalb mit "Cannot find module". Betroffen war nicht nur dieses
eine Skript, sondern alle, die im laufenden Behaelter gedacht sind - auch
wartungsschluessel.mjs und schluessel-erzeugen.mjs.
Kopiert wird jetzt das ganze Verzeichnis, nicht einzelne Dateien. Sonst
faellt beim naechsten Betriebsskript wieder auf, dass es fehlt - und zwar
erst dann, wenn man es braucht. Die Entwicklungsskripte darin laufen dort
mangels Werkzeugen nicht, kosten aber nur ein paar Kilobyte.
Geprueft im fertigen Abbild und gegen eine echte Datenbank: Das Skript
liegt unter /app/scripts, laeuft als Benutzer cockpit und gibt dasselbe
Geheimnis aus wie auf dem Entwicklungsrechner.
Die Anleitung nennt jetzt zusaetzlich den Weg fuer alle, die noch eine
aeltere Fassung laufen haben und nicht sofort aktualisieren wollen:
docker compose cp legt die Datei einmalig in den Behaelter.
Etappe: 8
Phase: Haertung
Die Anwendung zeigt das Geheimnis genau einmal an, beim Einrichten - das
ist richtig so. Wer den Zugang aber auf ein zweites Geraet legen will,
Handy und Tablet oder ein Ersatzgeraet im Schrank, braucht es noch
einmal. Bisher blieb dafuer nur, den zweiten Faktor zurueckzusetzen und
alle Wiederherstellungscodes neu zu erzeugen.
Das Skript laeuft nur auf dem Server und nur mit Zugriff auf die
Datenbank UND auf ENC_KEY_V1. Wer beides hat, kann ohnehin alles lesen -
genau deshalb liegt der Schluessel nicht in der Datenbank. Es ist also
keine Hintertuer, sondern erspart eine unnoetige Neueinrichtung.
Es gibt den otpauth-URI mit aus, aber mit dem ausdruecklichen Hinweis,
ihn in einen QR-Erzeuger auf demselben Rechner zu geben und nicht in
einen Dienst im Netz - sonst haette man das Geheimnis gerade dorthin
gegeben, wovor der zweite Faktor schuetzen soll.
Geprueft gegen den Entwicklungszugang: der ausgelesene Wert stimmt mit
SEED_DEV_TOTP_SECRET ueberein.
Etappe: 8
Phase: Haertung
Bis jetzt gab es Code und Betriebsdokumentation, aber nichts, was einem
beim Arbeiten hilft.
Die Anleitung ist kein Handbuch zum Durchlesen, sondern die zwoelf
Handgriffe, die im Alltag vorkommen - vom Behoerdenschreiben aufnehmen
bis zum Vertrag kuendigen. Dazu der Jahresrhythmus, die Berichte, was am
Handy anders ist, und ein Abschnitt "wenn etwas schiefgeht" mit den
Faellen, die wirklich passieren: Handy verloren, Code wird nicht
angenommen, Frist stimmt nicht, Bericht zeigt eine Differenz.
Ein eigener Abschnitt sagt, was die Anwendung NICHT tut. Wer sich auf
etwas verlaesst, das sie nicht leistet, faellt sonst genau dann darauf
herein, wenn es darauf ankommt.
Sie ist unter /anleitung auch in der Anwendung lesbar - dieselbe Datei,
kein zweiter Text, der auseinanderlaeuft. Wer im Heim steht und nicht
weiterweiss, hat sie auf dem Telefon dabei, und der Druckknopf legt sie
zu den Betreuungsunterlagen.
Dafuer ein schlichter Markdown-Baustein statt einer Bibliothek: die
Anwendung zeigt genau zwei solche Dokumente, beide schreibe ich selbst.
Rohes HTML wird nicht durchgereicht. Die Datenschutzseite benutzt ihn
jetzt ebenfalls, statt eine zweite Umsetzung zu pflegen.
Beide Dateien werden ueber outputFileTracingIncludes in den
Standalone-Build gezogen - der Pfad entsteht erst zur Laufzeit, die
Dateiverfolgung von Next.js kann ihn nicht erkennen. Ohne den Eintrag
waeren beide Seiten im Behaelter leer.
Die Roadmap sortiert die 44 Schema-Wuensche der Etappen nach einer
einzigen Frage zuerst: Kann daraus ein falscher Wert in einem Bericht
ans Gericht werden? Was das kann, steht in 1.1. Dazu ein Abschnitt
"bewusst nicht geplant" mit Begruendung - damit klar ist, worauf
niemand wartet.
Etappe: 8
Phase: Haertung
Florian Wilde