Claude
619515db96
Two hardening changes beyond just a password: - The admin panel no longer uses stored credentials at all. The backend generates a random API key on every startup and prints it to its own console (never through the DB-backed logger, since that's only reachable from inside the panel this key protects). Every /api/admin/* request must carry it as an X-Api-Key header, checked with a timing-safe comparison on every call — there's no session to create or steal, and restarting the backend invalidates the previous key immediately. The old admin_users and sessions tables, scrypt password hashing, and cookie-based session plumbing are removed entirely (dropped via migration for existing installs, not left behind unused). The login page keeps its existing layout but now asks for this key and explains where to find it, storing it in the browser's localStorage rather than relying on a server session. - The admin panel (the masthead's cog icon and the /admin/* pages themselves) is now disabled by default on every deployment, gated by a new frontend-only ADMIN_PANEL_ENABLED env var. This is a separate, UI-only visibility control — the API key above is what actually protects the backend regardless of this flag.
12 lines
700 B
Bash
12 lines
700 B
Bash
# Where the frontend talks to the backend (real or mock). Also settable at runtime
|
|
# via the connection setup screen, which saves to this browser's localStorage and
|
|
# takes priority over this build-time value — see src/lib/config.ts.
|
|
VITE_BACKEND_URL=http://localhost:4000
|
|
|
|
# The admin panel (cog icon in the masthead, and the /admin/* pages themselves) is
|
|
# disabled by default on every deployment. Set this to "true" to turn it on for a
|
|
# given deployment. This only controls whether the admin UI renders at all — the
|
|
# backend's per-launch API key (printed to its console on startup) is what actually
|
|
# protects every /api/admin/* request regardless of this setting.
|
|
ADMIN_PANEL_ENABLED=false
|