Anmeldung haerten: Einmalcodes, Anschluss, Host, Passkey-Vorzimmer

Vier Stellen, an denen eine Zusage nicht gehalten wurde.

1. Ein TOTP-Code galt mehrfach. Der Kommentar in totp.ts versprach seit
   dem Anfang, der Aufrufer speichere das getroffene Zeitfenster - getan
   hat es niemand. Damit liess sich ein abgelesener Code innerhalb von 90
   Sekunden noch einmal einloesen. Jetzt geht jede Pruefung durch
   zweitenFaktorEinloesen(), und die Bedingung steht im WHERE von
   updateMany: Zwei gleichzeitige Anmeldungen mit demselben Code treffen
   nicht beide eine Zeile.

2. Der Anschluss kam aus dem ERSTEN Eintrag von "x-forwarded-for". Das
   ist der Teil, den der Aufrufer selbst schreibt. Wer bei jeder Anfrage
   eine andere Zahl hineinschrieb, sah fuer die Anmeldesperre wie tausend
   Anschluesse aus - die Zaehlung war nicht nur wirkungslos, sondern
   irrefuehrend. Jetzt von hinten gelesen, und nur wenn VERTRAUE_PROXY
   gesetzt ist. Ohne Proxy ist der Kopf fremdbestimmt; dann lieber keine
   Zaehlung nach Anschluss als eine, die eine Kopfzeile aushebelt. Beim
   ersten Mal steht eine Zeile im Log, damit das Fehlen auffaellt.

3. trustHost stand fest auf true. Ist AUTH_URL gesetzt - der
   dokumentierte Betrieb setzt es, Passkeys brauchen es -, gibt es keinen
   Grund, die Adresse aus einer Kopfzeile von aussen abzuleiten.
   AUTH_TRUST_HOST bleibt wirksam, damit die dokumentierte Einstellung
   nicht stillschweigend uebergangen wird.

4. Passkeys liessen sich ohne erneute Bestaetigung anlegen und entfernen.
   Ein Passkey ist ein vollwertiger Zugang, der einen Passwortwechsel
   ueberlebt - an einem unbeaufsichtigten Rechner waren das zwei Klicks.
   Jetzt dasselbe Vorzimmer wie beim Vollexport. Dabei musste
   alsFehler() lernen, die Weiterleitung von Next durchzulassen: Sonst
   verschwand die Zwischenfrage in "Der Passkey konnte nicht geprueft
   werden".

Refs #38

src/lib/env.ts

@@ -31,6 +31,18 @@ function zahl(name: string, standard: number): number {
   return n
 }
 
+/**
+ * Ein Ja/Nein-Schalter. Bewusst nur "true"/"1"/"ja" als Ja - alles andere,
+ * auch ein Tippfehler, gilt als Nein. Bei einem Sicherheitsschalter ist das
+ * die richtige Richtung: Wer sich verschreibt, bekommt die strengere
+ * Einstellung, nicht die laxere.
+ */
+function schalter(name: string, standard = false): boolean {
+  const wert = process.env[name]?.trim().toLowerCase()
+  if (wert === undefined || wert === '') return standard
+  return wert === 'true' || wert === '1' || wert === 'ja'
+}
+
 function schluessel32(name: string): Buffer {
   const roh = pflicht(name)
   const buf = Buffer.from(roh, 'base64')
@@ -214,6 +226,65 @@ export const env = {
     }
   },
 
+  /**
+   * Darf der Host-Kopf der Anfrage die oeffentliche Adresse bestimmen?
+   *
+   * Standard: nur dann, wenn AUTH_URL nicht gesetzt ist. Ist die Adresse
+   * konfiguriert - der dokumentierte Betrieb setzt sie, Passkeys brauchen
+   * sie ohnehin -, gibt es keinen Grund, sie aus einer Kopfzeile von aussen
+   * abzuleiten. Vorher stand in auth.ts fest "true", und ein
+   * "X-Forwarded-Host: fremde.example" haette in erzeugte Adressen
+   * durchgeschlagen.
+   *
+   * AUTH_TRUST_HOST bleibt wirksam, damit die dokumentierte Einstellung
+   * nicht stillschweigend uebergangen wird.
+   */
+  get vertraueHost() {
+    return schalter('AUTH_TRUST_HOST', !process.env.AUTH_URL)
+  },
+
+  /**
+   * Geheimnis fuer die Ersteinrichtung.
+   *
+   * Zwischen dem ersten Start und dem Anlegen des Zugangs steht die Seite
+   * offen: Wer sie in diesem Fenster findet, legt sich selbst einen
+   * Administratorzugang an. Das Fenster ist kurz, aber es ist da - und bei
+   * einer Anwendung mit Gesundheits- und Finanzdaten ist "kurz" kein
+   * Argument.
+   *
+   * Ohne diesen Wert ist die Ersteinrichtung gesperrt. Das ist Absicht:
+   * Eine Installation, bei der das Feld vergessen wurde, soll nicht
+   * einrichtbar sein, sondern eine Meldung zeigen.
+   */
+  get ersteinrichtungGeheimnis() {
+    return process.env.ERSTEINRICHTUNG_GEHEIMNIS?.trim() ?? ''
+  },
+
+  /**
+   * Steht ein Reverse Proxy davor, dem die weitergereichten Koepfe zu
+   * glauben sind?
+   *
+   * Standard ist nein. Das ist die unbequeme, aber richtige Voreinstellung:
+   * Ohne Proxy ist "x-forwarded-for" frei erfunden, und eine Sperre, die
+   * darauf zaehlt, laesst sich mit einer Kopfzeile aushebeln. Wer einen
+   * Proxy davorstellt - der dokumentierte Betrieb tut das -, sagt es hier
+   * ausdruecklich. Siehe src/lib/auth/anschluss.ts.
+   */
+  get vertraueProxy() {
+    return schalter('VERTRAUE_PROXY', false)
+  },
+
+  /**
+   * Wie viele Zwischenknoten vertraut werden. Bei einem Proxy: 1.
+   *
+   * Die Zahl sagt, wie weit von hinten in der Kette der Aufrufer steht.
+   * Zu hoch gesetzt liest man wieder fremdbestimmte Eintraege, deshalb
+   * bleibt es bei eins, solange nichts anderes dasteht.
+   */
+  get vertraueProxyStufen() {
+    return Math.max(1, zahl('VERTRAUE_PROXY_STUFEN', 1))
+  },
+
   get istProduktion() {
     return process.env.NODE_ENV === 'production'
   },