fix(daemon): allow token-authenticated remote MCP clients#219
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughMCP transport authentication now rejects browser-originated requests first, validates bearer tokens before Host checks in token mode, and retains loopback Host allowlisting in open mode. Tests and self-hosting documentation cover remote token-authenticated clients and the updated restrictions. ChangesMCP transport authentication
Estimated code review effort: 3 (Moderate) | ~20 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
What & why
Fixes #218.
Remote MCP clients configured with a valid bearer token were rejected when they sent a public or reverse-proxy
Hostheader. The MCP transport applied its loopback Host allowlist before bearer-token validation, whichconflicted with the documented token-authenticated remote deployment model.
This change makes the bearer token the authorization boundary for remote MCP traffic while retaining the
browser-origin protection that prevents browser-driven access.
Changes
Originheader in both open and token-authenticated modes.Testing
tests/unit/daemon/http-server.test.ts(38/38)tsc --noEmitnpm testsuite: attempted, but unrelated failures occurred intests/unit/tools/find- similar.test.tsin this environmentChecklist
CONTRIBUTING.mdand agree to its contribution termsSummary by CodeRabbit
Bug Fixes
Documentation