Stub in OAuth endpoints to keep MCP cnxn alive.#12
Conversation
MCP clients (notably the Claude Code SDK) probe RFC 9728 discovery endpoints (/.well-known/oauth-authorization-server, /.well-known/oauth-protected-resource) when establishing a session. Without a binding for those paths, Eyre returns its HTML fallback (307 to /~/login or /apps/landscape/), causing the client to fail parsing the response as JSON and abort the handshake. Bind /.well-known to %mcp-server and respond with a JSON 404 from +handle-req. State bumps to %1 with the same shape; on-load emits the new connect card on upgrade so existing ships pick up the binding without reinstall.
Switch from apat:de-purl:html (whose return shape doesn't match what the dispatch needs at this kelvin) to a plain tape prefix comparison.
Groundwire Verification FailedThis PR will not be reviewed because commits are not signed by a recognized Groundwire ID. Why?This repository requires contributors to prove ownership of an onchain Groundwire identity. How to fix this
This repository is protected by Groundwire for GitHub. |
A 404 wasn't enough to keep the Claude Code SDK from chasing OAuth fallbacks (and hitting Eyre's HTML login page). Return a valid 200 protected-resource metadata document with no authorization servers and 'header' as the bearer method, signalling to clients that they should use the auth header they already have rather than initiating an OAuth handshake.
|
For #11. Stupidly, the /mcp dialog and the actual MCP connection are two different code paths. The connection works ( |
|
I think the state upgrade is unnecessary; I don't know of anyone running this on a non-disposable ship. Otherwise looks good so far, lmk when this is ready to review and merge. |
Claude Code's /mcp dialog runs an OAuth client-registration flow
that probes /oauth/authorize, /oauth/token, /oauth/register on the
configured MCP URL. Without a binding for these paths Eyre
redirects to /~/login (HTML), and the SDK errors out trying to
parse the response as JSON. The dialog failure marks the server
unhealthy and disconnects the session, even though cookie auth
on the underlying /mcp endpoint is fine.
Bind /oauth to %mcp-server and respond with a JSON error of shape
{error: 'unsupported_response_type', error_description: ...} for
all sub-paths. State bumps to %2; on-load emits the new connect
card on upgrade.
The Claude Code SDK (and any RFC-conformant MCP client) expects two different metadata shapes at two different /.well-known paths: - /.well-known/oauth-protected-resource: RFC 9728 (resource, authorization_servers, bearer_methods_supported) - /.well-known/oauth-authorization-server: RFC 8414 (issuer, authorization_endpoint, token_endpoint, response_types_supported, ...) Returning RFC 9728 metadata at both endpoints produced Zod validation errors against the RFC 8414 schema. Dispatch by path: return RFC 9728 at the protected-resource endpoint, a Zod-valid RFC 8414 stub at the auth-server endpoint, and JSON 404 for any other /.well-known/* probe. The actual OAuth endpoints under /oauth/* still return RFC 6749 errors -- the discovery passes, the flow fails cleanly without disconnecting the session.
Removed unused state versions and related comments.
Update state handling in mcp-server.hoon for better initialization.
No description provided.