stacklok / toolhive / 30339578062

coverage: 69.717% (+0.008%) from 69.709%
30339578062

push

github

web-flow 
Use standard JSON-RPC error codes and scrub leaked error text (#6066)

* Map HTTP statuses to standard JSON-RPC error codes

Three error paths passed the HTTP status straight through as the
JSON-RPC error.code: the authz response filter emitted a literal 500,
and both webhook middlewares emitted whatever status they were called
with (413, 422, or 500). Those values are legal, since they sit outside
the reserved -32768..-32000 range, but they are not the codes the draft
MCP spec designates for general protocol failures, so a client that
branches on error.code cannot recognize 500 as internal-error or 422 as
a denial.

The HTTP status and the JSON-RPC code are independent dimensions. Add
mcp.JSONRPCCodeForStatus as the single place the mapping lives: 413
becomes -32600 (an oversized body is a malformed request), 500 becomes
-32603, and 422 becomes JSONRPCCodeDenied, because the mutating path
relays a webhook's 422 always-deny response downstream while the
validating path relays the identical condition as 403 -- emitting 422
as the code would make one denial look unlike every other denial.

403 is unchanged. It is the one case where status and code legitimately
coincide, deliberately outside the reserved range so it never collides
with an SDK-generated code.

Deriving the code inside sendErrorResponse leaves all 13 call sites
untouched. The encode-failure fallback bodies are fixed too; they
spliced the raw status into the code field, so leaving them would
reintroduce the bug they stand in for.

No HTTP status changes, so audit outcomes -- which key off the status,
not the code -- are unaffected.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* Scrub internal error text on authorization denials

pkg/authz forwarded internal error text verbatim to callers on three
paths: the Cedar authorizer's evaluation error, a default-deny message
disclosing that a method is "not configured for authorization", and the
response filter's error, which can originat... (continued)

23 of 30 new or added lines in 5 files covered. (76.67%)

6 existing lines in 3 files now uncovered.

81086 of 116307 relevant lines covered (69.72%)

98.43 hits per line

Source File
Press 'n' to go to next uncovered line, 'b' for previous

87.6
/pkg/webhook/validating/middleware.go


Build SHA Not Found

The commit SHA "4a61bd1a59945bfbf84ea6a4e8c8af3c5f3cc764" was not found in your repository, so the file cannot be loaded. This may be because you posted from a local development environment, or your CI created an ephemeral commit.