Affected Component
server/core/auth.py
Question
_PUBLIC_PATHS (server/core/auth.py:22) exempts /docs, /redoc and /openapi.json from authentication along with the health and version endpoints. So on a deployment that has STATEWAVE_API_KEY set, the full API schema is still readable by anyone who can reach the port:
$ curl -s -o /dev/null -w '%{http_code}\n' http://localhost:8100/openapi.json
200Health and version being public is clearly deliberate and useful — probes and discovery need it. The schema endpoints feel like a different category, so I wanted to ask rather than assume: is that exemption intentional?
If it is, deployment/guide.md's production checklist would be a natural place to say so, so operators fronting Statewave with a proxy know to block those three paths themselves. If it isn't, gating them on settings.debug would keep the local-dev experience identical while closing them on keyed deployments.
Environment
statewavedev/statewave:latest (reports 1.5.0).
Affected Component
server/core/auth.pyQuestion
_PUBLIC_PATHS(server/core/auth.py:22) exempts/docs,/redocand/openapi.jsonfrom authentication along with the health and version endpoints. So on a deployment that hasSTATEWAVE_API_KEYset, the full API schema is still readable by anyone who can reach the port:Health and version being public is clearly deliberate and useful — probes and discovery need it. The schema endpoints feel like a different category, so I wanted to ask rather than assume: is that exemption intentional?
If it is,
deployment/guide.md's production checklist would be a natural place to say so, so operators fronting Statewave with a proxy know to block those three paths themselves. If it isn't, gating them onsettings.debugwould keep the local-dev experience identical while closing them on keyed deployments.Environment
statewavedev/statewave:latest(reports 1.5.0).