mrambossekandClaude Fable 5
cd187f9ef5
server-test / test (push) Successful in 34s
Two gaps found while answering where configuration lives. The confidential admin client needs a secret and there was nowhere to put one - I had added the issuer and both client ids but not the secret the admin login actually needs. It now reads from ECHOLOT_OIDC_CLIENT_SECRET, and preferably from ECHOLOT_OIDC_CLIENT_SECRET_FILE: a secret in the environment is readable by anything that can see /proc/<pid>/environ and lands in every dump of the unit's config, whereas a path is one file whose permissions an operator can reason about. (/etc/echolot-server.env was also 0644; now 0600 on fmr.) And the server now refuses to serve the admin UI in plaintext on a non-loopback address. The session cookie is a bearer credential for everything the server can do, and the OIDC authorization code arrives in a URL; in the clear, both belong to anyone on the path - and on a globally routable address that is the internet. A hard stop rather than a warning, because a warning in a log is not read by the person who most needs it, and because the safe answers are cheap: bind to loopback and tunnel, or supply a certificate. ECHOLOT_ADMIN_INSECURE=1 overrides it, so the decision is made rather than stumbled into. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>