Anmeldung: Host-Abweichung frueh erkennen, weniger auf der Anmeldeseite verraten

Im Betrieb aufgetreten: Die Anwendung lief hinter einem Reverse Proxy unter
einer Domain, in der .env stand aber noch die interne Adresse aus der
Einrichtung. Der Anmeldeknopf setzt den Cookie mit dem laufenden Vorgang auf
dem Host, ueber den der Browser da ist — die Rueckkehradresse fuer den
Anbieter kommt dagegen aus BASE_URL. Der Anbieter schickte den Browser also
auf den anderen Host, der Cookie blieb zurueck, und am Ende stand „Der
Anmeldevorgang ist abgelaufen". Eine Meldung, die die Ursache gut versteckt.

Jetzt prueft der Start beide Adressen und bricht sofort mit einer Erklaerung
ab. Auf dem Bildschirm steht nur die aufgerufene Adresse — die interne gehoert
ins Protokoll, nicht auf eine Seite, die jeder sieht.

Aus demselben Grund faellt der Hinweis „Die Anmeldung mit Passwort ist
abgeschaltet (OIDC_ONLY=true)" weg. Wie die Anmeldung eingerichtet ist, geht
Fremde nichts an; wer hierher gehoert, sieht den einen Knopf und weiss, was zu
tun ist. Beim allerersten Aufruf bleibt der Hinweis, dass der Erste
Administrator wird — der ist dann nuetzlich.

Dazu die Anleitungen: Der Reverse-Proxy-Abschnitt im README nennt jetzt die
drei Kopfzeilen, die die Anwendung vom Proxy erwartet, und was ohne sie
passiert; dazu client_max_body_size fuer Uploads, ein Weg zum Nachpruefen und
die Frage, fuer wen die Codes erreichbar sein sollen. In authentik.md steht,
warum BASE_URL und die Adresse im Browser dieselbe sein muessen.

docs/authentik.md

@@ -94,6 +94,34 @@ Zu beachten:
 > falsch eingestellt, sondern die `BASE_URL` — und die gehört korrigiert,
 > bevor der erste dynamische Code entsteht: Sie steckt in jedem davon.
 
+### `BASE_URL` und die Adresse im Browser müssen dieselbe sein
+
+Nicht nur „irgendeine erreichbare Adresse“ — **dieselbe**, über die ihr die
+Anwendung tatsächlich aufruft.
+
+Der Grund liegt im Ablauf: Beim Klick auf den Anmeldeknopf legt die Anwendung
+einen Cookie mit dem laufenden Vorgang ab — auf dem Host, über den der Browser
+gerade da ist. Die Rückkehradresse für Authentik kommt dagegen aus `BASE_URL`.
+Zeigen die beiden auf verschiedene Hosts, schickt Authentik den Browser auf den
+anderen Host, der Cookie bleibt beim ersten zurück, und die Anmeldung endet mit
+**„Der Anmeldevorgang ist abgelaufen“**. Erkennbar ist es daran, dass in der
+Adresszeile plötzlich eine andere Adresse steht als die, mit der man begonnen
+hat.
+
+Seit Version vom 17.08.2026 fängt die Anwendung das ab und nennt beide
+Adressen, statt den Vorgang bis zum Ende laufen zu lassen.
+
+Ein häufiges Muster: Die Anwendung läuft hinter einem Reverse Proxy unter
+`https://qr.example.com`, in der `.env` steht aber noch die interne Adresse
+`http://10.0.0.5:3005` aus der Einrichtung. Dann gehören **drei** Werte in
+Übereinstimmung gebracht:
+
+| | |
+| --- | --- |
+| Aufruf im Browser | `https://qr.example.com` |
+| `BASE_URL` in der `.env` | `https://qr.example.com` |
+| Redirect URI in Authentik | `https://qr.example.com/api/auth/oidc/callback` |
+
 ---
 
 ## Schritt 2 — Eine Application anlegen
@@ -259,7 +287,8 @@ Danach verschwindet das Passwortfeld von der Anmeldeseite.
 | Authentik zeigt „Redirect URI Error“ | Die Redirect URI im Provider stimmt nicht exakt mit `{BASE_URL}/api/auth/oidc/callback` überein — siehe [Die Redirect URI](#die-redirect-uri). Auf Schema, Port, Schrägstrich am Ende und die Auswahl Strict/Regex achten. |
 | „Der Anbieter hat keine E-Mail-Adresse geliefert“ | Der Scope `email` fehlt im Provider, oder der Benutzer hat in Authentik keine Adresse hinterlegt. |
 | „Der Anbieter hat die Anmeldung abgelehnt“ | Der Benutzer ist der Application in Authentik nicht zugeordnet — Policy/Group Binding prüfen. |
-| „Der Anmeldevorgang ist abgelaufen“ | Zwischen Klick und Rückkehr sind mehr als 10 Minuten vergangen, oder der Cookie ging verloren. Häufigste echte Ursache: `BASE_URL` zeigt auf eine andere Adresse als die, über die der Browser kommt. |
+| „Der Anmeldevorgang ist abgelaufen“ | Der Cookie mit dem laufenden Vorgang kam nicht zurück. Entweder sind mehr als 10 Minuten vergangen — oder, weit häufiger, `BASE_URL` zeigt auf einen anderen Host als den, über den der Browser kommt. Erkennbar daran, dass in der Adresszeile eine andere Adresse steht als beim Start. Siehe [BASE_URL und die Adresse im Browser](#base_url-und-die-adresse-im-browser-müssen-dieselbe-sein). |
+| „Du rufst die Anwendung über … auf, BASE_URL zeigt aber auf …“ | Genau der Fall von oben, nur früh erkannt. Die Meldung nennt beide Adressen; `BASE_URL` in der `.env` auf die erste setzen und `docker compose up -d` ausführen. |
 | „Das Anmelde-Token des Anbieters ist ungültig“ | Uhrzeit-Abweichung zwischen den Servern oder ein gewechselter Signaturschlüssel. Beides zeigt `docker compose logs app` genauer. |
 | Nach der Anmeldung fehlt die Verwaltung | `OIDC_ADMIN_GROUP` ist gesetzt, der Benutzer aber nicht in dieser Gruppe. Entweder die Gruppe in Authentik ergänzen oder die Variable leeren und das Recht hier vergeben. |