front: enforce the API bearer on /v1, and do not fall open (v0.2.84)
Reproduced on the published 0.2.83 image, GPU-less, no Authorization header:
GET /v1/models -> 200 <- open
POST /v1/chat/completions -> 503 (no model in the test, so inconclusive)
GET /v1/runpod/spend -> 502
Nothing returned 401, because the front was never an enforcement point: it
answers some /v1 paths from its own registry and proxies the rest, so
whether a request needed a token depended on which component served it. On
a host published through a reverse proxy that is an open relay for the
model list, and potentially for generation.
The front now gates /v1 itself with the same credentials the engine
accepts: the env token a capability image is locked with, the shared
cluster token a head presents, an API token from auth.json, a logged-in
browser session, the in-process broker bridge, and the aisbf relay marker.
Constant-time comparison throughout.
One deliberate difference from the engine's middleware: it does NOT fall
open when no credentials are configured. That fallback is defensible on a
loopback workstation and is precisely what exposed this one, so the front
refuses instead. Readiness and progress endpoints stay exempt — a probe
that 401s is read as "backend down", and surya-ocr's vLLM client probes
{service_url}/health.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>
Showing
Please
register
or
sign in
to comment