Release 0.2.0

2026-10-21 17:25:28 +02:00
1 parent 7a49e66c37
commit 08e8875cb5
@@ -39,3 +39,30 @@
 - Ein zusätzlicher Python-Playwright-Lauf: nicht gestartet, weil das optionale
  Python-Modul `playwright` nicht installiert war. Die projektgebundene
  TypeScript-Playwright-Suite lief stattdessen vollständig erfolgreich.
+
+## Etappe 2
+
+| Kriterium                       | Nachweis                                                                            | Stand                 |
+| ------------------------------- | ----------------------------------------------------------------------------------- | --------------------- |
+| Erstadmin danach geschlossen    | Browser-Setup sowie wiederholter Service-Aufruf geprüft; Seed enthält kein Konto    | erfüllt am 21.10.2026 |
+| Login, Logout und lokales HTTP  | Browserablauf; `HttpOnly`, `SameSite=Lax`, ohne `Secure` bei expliziter HTTP-Origin | erfüllt am 21.10.2026 |
+| Einladung und Reset             | lokale Outbox bis Kontoaktivierung und neuem Login im Browser durchlaufen           | erfüllt am 21.10.2026 |
+| Einmalige und abgelaufene Links | Verhaltenstests für Wiederverwendung und Ablauf von Einladung und Reset             | erfüllt am 21.10.2026 |
+| Direkte Admin-Aktion verweigert | Thekencrew-POST auf Einladungsaction liefert 403                                    | erfüllt am 21.10.2026 |
+| Sperrung entzieht Zugriff       | aktive Thekencrew-Sitzung wird gelöscht und beim nächsten Request abgewiesen        | erfüllt am 21.10.2026 |
+| Keine echte Mail ungefragt      | Browser- und Verhaltenstests nutzen ausschließlich temporäre lokale Outbox          | erfüllt am 21.10.2026 |
+| Echter SMTP-Versand             | nicht ausgeführt, keine Zugangsdaten bereitgestellt                                 | offen                 |
+
+## Ausgeführte Prüfungen Etappe 2
+
+- `npm run lint`: erfolgreich
+- `npm run check`: 0 Fehler und 0 Warnungen
+- `npm test`: 9 Auth-, Migrations-, Mail- und Dauer-Verhaltenstests erfolgreich
+- `npm run build`: erfolgreich mit `@sveltejs/adapter-node`
+- `npm run test:e2e`: 9 von 9 Browsertests erfolgreich; Erstadmin,
+  Login/Logout, fremder Origin, Einladung, direkte Rollenprüfung, Sperrung,
+  Reset sowie bestehende responsive Arbeitsansichten geprüft
+- Lokale Outbox in isolierten temporären Verzeichnissen geprüft
+- Lokaler Produktionsserver der Browsertests über HTTP gestartet; Healthcheck
+  und Migration vor Start erfolgreich
+- `bash -n start.sh`: erfolgreich
@@ -38,7 +38,7 @@ Kern. Folgende Grenzen sind für spätere Migrationen bereits festgelegt.

 | Bereich     | Geplante Entitäten und Beziehungen                                                                                           |
 | ----------- | ---------------------------------------------------------------------------------------------------------------------------- |
-| Identität   | `users`, Rollen, Sessions, Einladungen, Reset-Tokens, Sperren und technische Zugänge; Tokens nur gehasht                     |
+| Identität   | `users`, Rollen, Sessions, Einladungen, Reset-Tokens und Sperren sind umgesetzt; technische Zugänge folgen später            |
 | Taxonomie   | getrennte `section_categories`, `formats`, `topics`; Pieces und Vorschläge über Zuordnungstabellen mehrfach verknüpft        |
 | Inhalt      | `pieces` mit Status und Dauer; Quellen, Medien, private Recherche, Moderation, Präsentation und Vorlagen als getrennte Daten |
 | Sendungsbau | `shows`, geordnete `show_sections`, kopierte `piece_usages`, Reservebank und Sendungsvorlagen; Original-ID bleibt Referenz   |
@@ -63,6 +63,32 @@ oder eine explizite Abschnittsdauer. Beides wird nie addiert. Reserveelemente
 zählen erst nach dem Einplanen. Geplante und tatsächliche Dauer bleiben
 getrennt.

+## Anmeldung und Rechte
+
+Etappe 2 ergänzt lokale Konten mit den festen Rollen `barkeeper` und
+`thekencrew`. Passwörter werden mit Argon2id gespeichert. Sitzungs-, Einladungs-
+und Reset-Tokens entstehen aus kryptografischem Zufall; in SQLite liegt jeweils
+nur ihr SHA-256-Hash. Der Browser erhält ausschließlich das rohe Sitzungstoken
+in einem `HttpOnly`-, `SameSite=Lax`-Cookie.
+
+`hooks.server.ts` löst die Sitzung für jeden Request auf. Die Datenbankabfrage
+verbindet die Session immer mit dem aktuellen Nutzerzustand, sodass Sperren und
+Rollenwechsel ohne verzögerte Token-Erneuerung wirken. Geschützte Routen
+erfordern eine Anmeldung; Verwaltungs-Loads und jede Verwaltungs-Action prüfen
+zusätzlich die Barkeeper-Rolle. Sperrung und Passwortwechsel löschen bestehende
+Sessions transaktional.
+
+Der Erstadmin benötigt sowohl eine leere Nutzertabelle als auch ein extern
+konfiguriertes Setup-Token. Einladungs- und Reset-Links sind 24 Stunden gültig,
+werden erst beim bestätigenden POST verbraucht und sind genau einmal nutzbar.
+Fehlgeschlagene Loginversuche werden pro E-Mail-Schlüssel und Clientadresse in
+einem Zeitfenster begrenzt, ohne das Konto dauerhaft zu sperren.
+
+Mail verwendet einen Adapter: `local` schreibt geschützte Dateien in den
+konfigurierten Outbox-Pfad, `smtp` nutzt Nodemailer nur nach expliziter Auswahl.
+Die feste Anwendungs-Origin erzeugt Links und bestimmt den `Secure`-Status der
+Cookies; sie wird nicht aus ungeprüften Request-Headern übernommen.
+
 ## Oberflächenstruktur

 Die Hauptnavigation umfasst Eingang, Fundus, Sendungen, Archiv und Verwaltung.
@@ -81,8 +107,8 @@ Fachabläufe werden jedoch nicht vorgetäuscht.

 ## Sicherheitsgrenzen ab den Folgeetappen

-Authentifizierung und Autorisierung werden serverseitig an jeder Route und
-Action geprüft. Markdown und fremdes HTML werden vor Ausgabe bereinigt.
+Authentifizierung und Autorisierung werden seit Etappe 2 serverseitig an jeder
+betroffenen Route und Action geprüft. Markdown und fremdes HTML werden vor Ausgabe bereinigt.
 Uploadzugriff folgt denselben Rechten. Netzwerkabrufe erhalten Schutz gegen
 interne Ziele, Größen-/Zeitlimits und kontrollierte Redirects. Diese Regeln
 sind geplant, aber nicht Bestandteil der Etappe-1-Vorschauen.
@@ -94,3 +94,44 @@ Der Fundus erscheint auf dem Desktop als kompakte Liste und auf kleinen
 Bildschirmen als Kartenfolge. Vorschau- und Schreibschutzinformationen sind in
 einem nativen, tastaturbedienbaren `details`-Element gebündelt. Diese
 Darstellungsentscheidung ändert weder Datenmodell noch Funktionsumfang.
+
+## D-008: Widerrufbare Datenbanksitzungen und Argon2id
+
+Sendewerk verwendet Datenbanksitzungen statt JWT. SvelteKit empfiehlt diesen
+Ansatz, wenn sofortiger Widerruf wichtiger als eine zusätzliche Datenbankabfrage
+ist. Ein zufälliges Sitzungstoken liegt nur als SHA-256-Hash in SQLite; der
+Browser erhält es als `HttpOnly`-, `SameSite=Lax`-Cookie. Nutzerstatus und Rolle
+werden bei jedem Request erneut verbunden. Lokal erlaubt eine explizite
+`http:`-Origin Cookies ohne `Secure`, bei `https:` wird `Secure` gesetzt.
+
+Passwörter hasht `@node-rs/argon2` 2.2.2 mit Argon2id und den dokumentierten
+Paketparametern. Zufallstokens und SHA-256 stammen aus `node:crypto`; eigene
+Kryptoprimitive werden nicht implementiert.
+
+Quellen:
+
+- <https://svelte.dev/docs/kit/auth>
+- <https://svelte.dev/docs/kit/hooks>
+- <https://github.com/napi-rs/node-rs/tree/main/packages/argon2>
+
+## D-009: Form-Actions, geschlossenes Setup und Rollenprüfung
+
+Alle Auth-Schreibvorgänge verwenden POST-Form-Actions beziehungsweise einen
+POST-Endpunkt. SvelteKits gleichursprüngliche Formularprüfung bleibt aktiv. Der
+Erstadmin erfordert ein mindestens 32 Zeichen langes Betreiber-Setup-Token und
+eine transaktional geprüfte leere Nutzertabelle. Danach bleibt `/setup`
+geschlossen. Barkeeper-Rechte werden in jeder Verwaltungsaktion erneut geprüft;
+UI-Sichtbarkeit ist keine Sicherheitsgrenze.
+
+Quelle: <https://svelte.dev/docs/kit/form-actions>
+
+## D-010: Lokale Mail-Outbox als sichere Vorgabe
+
+Der Mailmodus ist standardmäßig `local` und schreibt Einladungs-/Resetnachrichten
+in einen konfigurierten persistenten Pfad. Dadurch wird lokal keine echte Mail
+ungefragt versandt. Nur die explizite Auswahl `smtp` initialisiert Nodemailer;
+bei SMTP sind Host und Absender verpflichtend. Outbox-Dateien sind private
+Geheimnisträger und werden weder versioniert noch über eine Route ausgeliefert.
+
+Nodemailer 10.1.7 unterstützt Node 20 oder neuer und ist MIT-0-lizenziert.
+Quelle: <https://github.com/nodemailer/nodemailer>
@@ -2,8 +2,9 @@

 ## Aktueller Umfang

-Etappe 1 ist abgeschlossen. Architektur, Gesamtdatenmodell, Entscheidungen und
-lokaler Betriebsweg sind dokumentiert. Etappe 2 wurde nicht begonnen.
+Etappe 1 und Etappe 2 sind abgeschlossen. Architektur, Gesamtdatenmodell,
+Anmeldung, Rollen und lokaler Betriebsweg sind dokumentiert. Etappe 3 wurde
+nicht begonnen.

 ## Umgesetzter Stand Etappe 1

@@ -36,11 +37,22 @@ umgebrochen.

 ## Nicht Bestandteil dieser Etappe

-Anmeldung, Rollen, echte Inhaltsbearbeitung, Autospeichern, Sendungsplanung,
-Live-Steuerung, Präsentationsfenster, Archivabschluss, Freigaben, RSS und API.
+Echte Inhaltsbearbeitung, Autospeichern, Sendungsplanung, Live-Steuerung,
+Präsentationsfenster, Archivabschluss, Freigaben, RSS und API.
 Die Vorschauen dürfen nicht als Implementierung dieser Funktionen verstanden
 werden.

+## Umgesetzter Stand Etappe 2
+
+- einmalige Erstadmin-Einrichtung mit externem Betreiber-Token
+- Login und POST-Logout mit widerrufbaren Datenbanksitzungen
+- Rollen Barkeeper und Thekencrew mit serverseitiger Prüfung
+- Einladungen und Passwortreset über befristete, einmalige Links
+- Kontensperrung mit sofortigem Entzug bestehender Sitzungen
+- zeitfensterbasiertes Login-Rate-Limit ohne dauerhafte Kontensperre
+- lokale Mail-Outbox als Vorgabe und explizit konfigurierbarer SMTP-Versand
+- responsive Authentifizierungs- und Kontenverwaltungsoberflächen
+
 ## Bekannte offene Betriebsprüfung

 Eine echte Cloudron-Installation samt Backup/Restore, Reverse-Proxy-Verhalten