chore: neue Umgebungsvariablen in .env.example und Compose

APP_NAME, APP_TAGLINE und APP_URL sowie SESSION_TTL_DAYS und die drei
Schalter des SSRF-Schutzes werden an den App-Container durchgereicht.

Bei APP_URL steht ausdruecklich dabei, dass daraus die WebAuthn-rpID
abgeleitet wird, dass Passkeys einen sicheren Kontext brauchen und dass ein
spaeterer Hostnamenwechsel bestehende Passkeys ungueltig macht.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

.env.example

@@ -4,6 +4,28 @@
 #  (Die .env wird sowohl von Next.js als auch von docker compose gelesen.)
 # ─────────────────────────────────────────────────────────────
 
+# ── Anwendung ────────────────────────────────────────────────
+# Anzeigename: Seitentitel, Kopfzeile und Name im Passkey-Dialog.
+APP_NAME="Nebula"
+# Kleine Zeile unter dem Namen in der Kopfzeile.
+APP_TAGLINE="Vibe Coding"
+
+# Oeffentliche Adresse der Instanz – genau so, wie du sie im Browser aufrufst.
+#
+# WICHTIG fuer Passkeys: Daraus werden die WebAuthn-Relying-Party-ID (der
+# Hostname) und der erwartete Origin abgeleitet. Passt der Wert nicht zur
+# aufgerufenen Adresse, lehnt der Browser die Anmeldung ab. Passkeys brauchen
+# ausserdem einen sicheren Kontext: https:// – oder http://localhost.
+#
+# Wird die rpID spaeter geaendert (anderer Hostname), sind bestehende Passkeys
+# ungueltig und muessen neu angelegt werden. Passwoerter bleiben davon unberuehrt.
+APP_URL="http://localhost:3000"
+
+# Port innerhalb des Containers bzw. im Standalone-Betrieb
+PORT="3000"
+# Host-Port-Mapping fuer den App-Container (--profile full)
+APP_PORT="3000"
+
 # ── Datenbank ────────────────────────────────────────────────
 # Standalone-Betrieb: App laeuft lokal, Postgres via "docker compose up -d db"
 # oder als nativ installierter Dienst.
@@ -18,23 +40,39 @@ POSTGRES_PASSWORD="nebula"
 POSTGRES_DB="nebula"
 # Host-Port, unter dem die Datenbank erreichbar ist
 POSTGRES_PORT="5432"
+# Host-Port fuer Adminer (--profile tools)
+ADMINER_PORT="8080"
 
 # ── Sicherheit ───────────────────────────────────────────────
 # Schluessel zur Verschluesselung der Git-Access-Tokens (AES-256-GCM).
 # Erzeugen mit:  openssl rand -base64 32
 #           oder: node -e "console.log(require('crypto').randomBytes(32).toString('base64'))"
 #           oder: npm run setup   (legt die .env inkl. Schluessel an)
-# WICHTIG: Wird der Wert nachtraeglich geaendert, sind gespeicherte Tokens
-# nicht mehr entschluesselbar und muessen neu hinterlegt werden.
+# WICHTIG: Wird der Wert nachtraeglich geaendert, sind gespeicherte Git-Tokens
+# nicht mehr entschluesselbar und muessen neu hinterlegt werden. Anmeldungen
+# und Passkeys sind davon nicht betroffen.
 APP_SECRET="bitte-aendern-mindestens-32-zeichen-langer-zufallswert"
 
-# ── App ──────────────────────────────────────────────────────
-# Port innerhalb des Containers bzw. im Standalone-Betrieb
-PORT="3000"
-# Host-Port-Mapping fuer den App-Container (--profile full)
-APP_PORT="3000"
-# Host-Port fuer Adminer (--profile tools)
-ADMINER_PORT="8080"
+# Lebensdauer einer Anmeldung in Tagen.
+SESSION_TTL_DAYS="30"
 
+# ── Ausgehende Git-Zugriffe ──────────────────────────────────
 # Timeout fuer Git-API-Aufrufe in Millisekunden
 GIT_API_TIMEOUT_MS="15000"
+
+# Schutz vor Server Side Request Forgery: die Basis-URL einer Git-Verbindung
+# ist eine Benutzereingabe und wird vom Server abgerufen.
+#
+# Voreinstellung: Loopback, Link-Local (169.254.x, Cloud-Metadaten), Multicast
+# und CGNAT sind gesperrt; das private LAN ist erlaubt, weil dort ueblicherweise
+# die eigene Gitea-Instanz steht.
+
+# Gitea laeuft auf demselben Rechner wie Nebula? Dann auf true setzen.
+# GIT_ALLOW_LOOPBACK="false"
+
+# Kein Zugriff ins private Netz (10/8, 172.16/12, 192.168/16, fc00::/7)?
+# GIT_BLOCK_PRIVATE="false"
+
+# Strengster Modus: nur diese Hosts sind erlaubt, alles andere wird geblockt.
+# Eine Angabe hier hebt die beiden Schalter darueber auf.
+# GIT_ALLOWED_HOSTS="github.com,gitlab.com,git.meine-firma.de"