Vorlage deploy/voice-assistant.user.service + Anleitung (loginctl enable-linger,
systemctl --user). Laeuft ohne root und ueberlebt Logout/Reboot; .env wird aus dem
WorkingDirectory gelesen. va_llm-Container kommt via Docker restart-policy hoch.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Discovery zeigte: YunoHost reicht den Usernamen nicht als Header durch, sondern im
signierten Cookie "yunohost.portal" (JWT, Claim "user"). Die Forward-Auth liest jetzt
die Identitaet aus Header ODER Cookie - nur von der Proxy-Quell-IP akzeptiert.
HS256-Signaturpruefung optional via TRUSTED_AUTH_JWT_SECRET (stdlib hmac, kein Dep).
- config: trusted_auth_cookie / _cookie_claim / _jwt_secret
- nginx-Vorlage + deploy/README: keine Identitaets-Header-Zeile mehr noetig; SSO-Schutz
der Subdomain ist Pflicht (sonst Spoofing)
- Tests: Cookie-Extraktion, Signaturpruefung, Proxy-IP-Trust
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Kuerzer und ohne die Verwechslungsgefahr assistent/assistant (de/en).
nginx-Vorlage umbenannt + alle Referenzen in deploy/README.md angepasst.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Beim SSO-Setup kennt das Gateway den Admin-Nutzer noch nicht (Henne-Ei). Der
Discovery-Endpoint /api/admin/request-headers akzeptiert daher zusaetzlich den
ADMIN_API_KEY als Query (?key=) oder X-Admin-Key-Header, damit man den von SSOwat
injizierten Identitaets-Header im Browser bestimmen kann. Doku entsprechend.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
