Release 0.2.0

docs/ARCHITECTURE.md

@@ -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.