Phase 5 abgeschlossen: Dateien mit vollständiger Prüfkette

Upload → quarantine/ → Typprüfung → ClamAV → Neukodierung → store/. Es gibt
keinen Pfad, auf dem eine Datei ungeprüft in store/ landet, und keinen
Schalter, der die Kette abschaltet.

Die Typprüfung liest Magic Bytes aus einer eigenen Signaturtabelle statt aus
file-type: bei einer Positivliste aus fünf Formaten hilft es nicht, hundert
erkennen zu können. Die Signatur muss an Position 0 stehen - ein Vorspann vor
%PDF- ist der klassische Weg, eine Datei für zwei Programme zugleich lesbar zu
machen. Wer trotzdem durchkommt, kommt als text/plain durch und wird unter der
Endung des erkannten Typs ausgeliefert, nicht unter der hochgeladenen.

Drei Ausgänge statt zwei: BLOCKED heisst "ist gefährlich", FAILED heisst
"wissen wir nicht". Nur FAILED lässt sich freigeben, und die Freigabe
wiederholt die Kette ohne den Scanner - Typprüfung und Neukodierung laufen
dabei mit. Ein fehlender clamd macht damit keine Datei sauber; ein Test hält
das fest.

Auslieferung nur über /api/files/[id], mit Sichtbarkeitsprüfung der
zugehörigen Akte, Protokoll ab Stufe 3 und den harten Kopfzeilen aus docs/07.
Vorschaubilder dürfen inline, weil sie serverseitig als WebP neu kodiert
wurden.

Das Lichtbild im Aktenblatt ist damit gefüllt: der Feldwert ist die Kennung
eines geprüften Anhangs, serverseitig zu einer Adresse aufgelöst.

/api/events liefert attachment.scanned über pg_notify - die Grundlage, auf der
Phase 6 den Aktenchat aufsetzt. Die Sichtbarkeit wird je Ereignis geprüft,
sonst verriete schon die Kennung die Existenz.

Nebenbei riss das Bündelbudget (121 kB gegen 120 erlaubte): lib/i18n/de.ts war
ein Objekt, und eine Client-Komponente zieht die ganze Datei mit. Die Texte
stehen jetzt in sechs Dateien nach Bereichen, de.ts setzt sie nur zusammen.
Grösste Route wieder bei 118 kB, und sie wächst nicht mehr mit jedem neuen
Bereich mit.

133 Tests im Web-Paket, 15 in der Datenbank, 28 e2e.

web/lib/realtime/listener.ts

@@ -1,20 +1,38 @@
 import { Client } from 'pg'
 import { invalidateAll, invalidateUser } from '@/lib/auth/effective'
+import { ATTACHMENT_CHANNEL } from '@/lib/realtime/publish'
 
 /**
  * Ein einziger `pg`-Client hält `LISTEN` offen und verteilt im Prozess weiter.
  * Kein WebSocket, kein Redis: Postgres `LISTEN/NOTIFY` reicht bei dieser
  * Nutzerzahl vollständig. Siehe docs/06-chat-und-realtime.md.
  *
- * Phase 1 nutzt zwei Kanäle: `member_changed` verwirft die Rechte eines
- * Nutzers, `role_mapping_changed` verwirft alles. Dadurch ist eine
- * Rechteänderung in Discord in unter einer Sekunde wirksam, ohne dass ein
- * einziger Request auf die Discord-API wartet.
+ * Drei Kanäle: `member_changed` verwirft die Rechte eines Nutzers,
+ * `role_mapping_changed` verwirft alles. Dadurch ist eine Rechteänderung in
+ * Discord in unter einer Sekunde wirksam, ohne dass ein einziger Request auf
+ * die Discord-API wartet. `attachment_scanned` meldet das Ende einer
+ * Dateiprüfung an die offenen Ansichten.
  *
  * Die Verbindung läuft an pgbouncer vorbei: im Transaktionsmodus überlebt ein
  * `LISTEN` den Pool nicht.
  */
-const CHANNELS = ['member_changed', 'role_mapping_changed'] as const
+const CHANNELS = ['member_changed', 'role_mapping_changed', ATTACHMENT_CHANNEL] as const
+
+/**
+ * Wer im Prozess auf Ereignisse wartet. Ein `Set` von Rückrufen statt eines
+ * EventEmitters, damit klar bleibt, dass hier nichts gepuffert wird: wer nicht
+ * verbunden ist, verpasst das Ereignis und holt sich den Stand beim nächsten
+ * Laden.
+ */
+type Subscriber = (event: { channel: string; payload: string }) => void
+
+const globalForSubscribers = globalThis as unknown as { afisSubscribers?: Set<Subscriber> }
+const subscribers = (globalForSubscribers.afisSubscribers ??= new Set<Subscriber>())
+
+export function subscribe(listener: Subscriber): () => void {
+  subscribers.add(listener)
+  return () => subscribers.delete(listener)
+}
 
 type Listener = { client: Client; ready: Promise<void> }
 
@@ -33,6 +51,16 @@ function connect(): Listener {
     }
     if (message.channel === 'role_mapping_changed') {
       invalidateAll()
+      return
+    }
+    if (message.payload) {
+      for (const listener of subscribers) {
+        try {
+          listener({ channel: message.channel, payload: message.payload })
+        } catch (error) {
+          console.error('[realtime] Empfänger hat geworfen', error)
+        }
+      }
     }
   })
 

web/lib/realtime/publish.ts

@@ -0,0 +1,22 @@
+import { db } from '@/lib/db'
+
+/**
+ * Ereignisse an alle offenen Ansichten schicken.
+ *
+ * Über `pg_notify`, nicht über einen prozessinternen Verteiler: dann stimmt es
+ * auch, wenn später ein zweiter Web-Prozess dazukommt, und es braucht keinen
+ * zusätzlichen Dienst. Siehe docs/06-chat-und-realtime.md.
+ */
+
+export const ATTACHMENT_CHANNEL = 'attachment_scanned'
+
+export async function notifyAttachmentScanned(attachmentId: string): Promise<void> {
+  try {
+    // Der Kanalname ist eine Konstante, nur die Nutzlast kommt von aussen —
+    // und die ist eine Kennung aus der Datenbank.
+    await db.$executeRaw`SELECT pg_notify(${ATTACHMENT_CHANNEL}, ${attachmentId})`
+  } catch (error) {
+    // Ein verlorenes Ereignis kostet eine Aktualisierung von Hand, mehr nicht.
+    console.error('[realtime] Ereignis nicht zugestellt', error)
+  }
+}