mrhid6
dc6e1b3c29
serverTouchingRoutes in cmd/main.go filtered on "server"/"console"/an exact workflows-run match, which is how POST /api/keys/:id/assign reached production with no scope check and no boot-time signal at all: its path names neither. Widen the filter to also match ":serverId" and "assign", and document at the filter why a substring match is the weak part of this design — a route that acts on a server without saying so in its path stays invisible to it — noting that inverting the model (every /api route declares itself, with an exemption list) would be the stronger fix and is left as a follow-up. Re-running the mechanical check against the widened filter swept in no route beyond what serverScopedRoutes already declared. GET /api/keys/:id also leaked out-of-scope hostnames: it returned every assignment for a key, server attached, unfiltered by the caller's tag restriction. getKey now drops any assignment whose server fails services.ServerInTokenScope before returning the list — silently, so the response carries no count of what was removed — while still returning the key itself, since a restricted token may legitimately hold a key also assigned outside its scope. GetAssignmentsWithServers has exactly one caller (getKey), so the filtering is done in the handler rather than threaded into the service. Recorded in serverScopedRoutes; its path matches none of the filter's substrings either, so it is not boot-enforced and is kept as a considered decision, same as the assign/revoke entries.