The startup banner printed `/setup?token=...`, so the one-hour bootstrap
token that grants the setup wizard landed in reverse-proxy access logs,
Referer headers and browser history. The link now carries the token in
the fragment, which never leaves the browser, and the wizard removes it
from the address bar as soon as it reads it. Old `?token=` links still
work and are cleaned up the same way.
The setup wizard and the admin sign-in set their session cookies by two
different rules. The wizard matches Secure to the request - X-Forwarded-
Proto from the proxy, else the URL scheme - because browsers drop Secure
cookies on plain HTTP and an unconditional Secure broke setup over HTTP.
The admin cookie kept `secure: NODE_ENV === 'production'`, so on the same
HTTP deployment the wizard worked and admin sign-in failed silently: the
cookie was set, the browser threw it away, every call came back 401.
Both now share one helper, lib/security/request-protocol.ts, and the admin
route passes its request in. Behind a TLS proxy that forwards the proto
nothing changes: the cookie is Secure as before. Callers that pass no
request keep the production default.
Linus Rath
lucamzanon