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

.env.example

@@ -15,9 +15,17 @@ DATABASE_URL="postgresql://cockpit:bitte-aendern@localhost:5432/betreuungs_cockp
 # 32 zufaellige Bytes, base64. Erzeugen: npm run schluessel
 AUTH_SECRET=
 # Oeffentliche Basis-URL der Anwendung (ohne abschliessenden Slash).
+# Hinter einem Proxy die Adresse, die im Browser in der Adresszeile steht -
+# nicht die interne. Passkeys pruefen dagegen.
 AUTH_URL=http://localhost:3000
-# Hinter einem Reverse Proxy auf true setzen.
-AUTH_TRUST_HOST=true
+
+# Darf der Host-Kopf der Anfrage die Adresse bestimmen?
+#
+# Solange AUTH_URL gesetzt ist: nein, und die Zeile bleibt weg. Die Adresse
+# ist dann bekannt und muss nicht aus einer Kopfzeile abgeleitet werden, die
+# von aussen kommt. Ein "X-Forwarded-Host: fremde.example" schlaegt sonst in
+# erzeugte Adressen durch.
+# AUTH_TRUST_HOST=true
 
 # --- Erreichbarkeit: HIER MUSST DU DICH ENTSCHEIDEN -------------------------
 #
@@ -73,6 +81,25 @@ LOGIN_MAX_VERSUCHE=5
 LOGIN_FENSTER_SEKUNDEN=900
 LOGIN_SPERRE_SEKUNDEN=900
 
+# Geheimnis fuer die Ersteinrichtung. OHNE DIESEN WERT LAESST SICH DER ERSTE
+# ZUGANG NICHT ANLEGEN - das ist Absicht.
+#
+# Zwischen dem ersten Start und dem Anlegen des Zugangs stand die
+# Einrichtungsseite sonst offen: Wer sie in diesem Fenster findet, wird
+# Administrator. Erzeugen: npm run schluessel
+ERSTEINRICHTUNG_GEHEIMNIS=
+
+# Steht ein Reverse Proxy davor?
+#
+# Nur mit "true" wird "X-Forwarded-For" geglaubt - und dann von HINTEN
+# gelesen, weil der vordere Teil der Liste vom Aufrufer selbst kommt.
+# Ohne diese Zeile zaehlt die Anmeldesperre nur nach E-Mail-Adresse.
+#
+# Der dokumentierte Betrieb (Reverse Proxy davor) braucht sie also:
+VERTRAUE_PROXY=true
+# Bei mehreren gestaffelten Proxys deren Anzahl. Sonst weglassen.
+# VERTRAUE_PROXY_STUFEN=1
+
 # --- Objektspeicher (S3-kompatibel, EU!) ------------------------------------
 # Wird ab Etappe 3 verwendet. Beispiel: Hetzner Object Storage, Falkenstein.
 # ACHTUNG: Mit dem Anbieter muss ein AV-Vertrag nach Art. 28 DSGVO bestehen.