Affected Component
Deployment / Docker Compose, server/core/auth.py
Bug Description
The admin service in docker-compose.yml defaults its API key to a placeholder and justifies it in a comment:
Reads STATEWAVE_API_KEY from your environment / .env, falling back to a local dev placeholder so a fresh docker compose up -d works with no setup (the api runs STATEWAVE_DEBUG=true and accepts any X-API-Key value).
The API does not behave that way. server/core/auth.py:32 skips authentication only when no key is configured — settings.debug is never consulted by the middleware — and auth.py:50 rejects a mismatch with compare_digest.
So for any operator whose .env sets STATEWAVE_API_KEY (which deployment/guide.md tells them to do), docker compose up -d starts an admin console that authenticates with dev-local-placeholder and gets a 403 on every call.
Expected Behavior
Either the comment reflects what auth.py actually does, or the admin default resolves to the same key the API is using. The failure should not be silent at startup.
Steps to Reproduce
- Put
STATEWAVE_API_KEY=<any real key> in .env next to docker-compose.yml.
docker compose up -d
- Open the admin console at http://localhost:8080, or call the API with the placeholder directly:
$ curl -s -o /dev/null -w '%{http_code}\n' -H 'X-API-Key: dev-local-placeholder' http://localhost:8100/v1/subjects
403
$ curl -s -o /dev/null -w '%{http_code}\n' -H "X-API-Key: $STATEWAVE_API_KEY" http://localhost:8100/v1/subjects
200
Environment
statewavedev/statewave:latest (reports 1.5.0), Docker Compose, Windows 11 host, pgvector/pgvector:pg16.
Severity
Low — local-dev ergonomics, no security impact. The placeholder is rejected correctly; only the explanation is wrong.
Additional Context
Found while pointing an external MCP client at a keyed local server. The same wrong mental model ("debug mode means auth is off") sends people looking in the wrong place when they hit a 401/403.
Affected Component
Deployment / Docker Compose,
server/core/auth.pyBug Description
The
adminservice indocker-compose.ymldefaults its API key to a placeholder and justifies it in a comment:The API does not behave that way.
server/core/auth.py:32skips authentication only when no key is configured —settings.debugis never consulted by the middleware — andauth.py:50rejects a mismatch withcompare_digest.So for any operator whose
.envsetsSTATEWAVE_API_KEY(whichdeployment/guide.mdtells them to do),docker compose up -dstarts an admin console that authenticates withdev-local-placeholderand gets a 403 on every call.Expected Behavior
Either the comment reflects what
auth.pyactually does, or the admin default resolves to the same key the API is using. The failure should not be silent at startup.Steps to Reproduce
STATEWAVE_API_KEY=<any real key>in.envnext todocker-compose.yml.docker compose up -dEnvironment
statewavedev/statewave:latest(reports 1.5.0), Docker Compose, Windows 11 host,pgvector/pgvector:pg16.Severity
Low — local-dev ergonomics, no security impact. The placeholder is rejected correctly; only the explanation is wrong.
Additional Context
Found while pointing an external MCP client at a keyed local server. The same wrong mental model ("debug mode means auth is off") sends people looking in the wrong place when they hit a 401/403.