feat(web): OAuth consent page for the new OAuth 2.1 provider; fix mcp resource metadata#933
Conversation
… resource metadata
How to use the Graphite Merge QueueAdd the label Main to this PR to add it to the merge queue. You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
supermemory-mcp | 678c7c6 | May 13 2026, 10:22 PM |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
supermemory-app | 678c7c6 | Commit Preview URL | May 13 2026, 10:23 PM |
There was a problem hiding this comment.
Reviewed the OAuth consent page and MCP resource metadata changes. The consent page is well-built with good error handling (HMAC expiry, signature validation). Key concerns: (1) org-switching interaction with HMAC-signed params, (2) deployment must be coordinated with mono PR #1552, (3) x-forwarded-host spoofing in dev mode.
| // so it must be byte-for-byte what we were redirected with (not re-serialized). | ||
| const oauthQuery = window.location.search.replace(/^\?/, "") | ||
| if (!oauthQuery) { | ||
| setError( |
There was a problem hiding this comment.
changeOrg calls authClient.organization.setActive but doesn't refresh the consent page's query params. After switching orgs, the HMAC-signed query string still references the original session state. Will the consent POST succeed with the new active org, or will the server reject it because the session changed mid-flow?
| redirectURI?: string | ||
| redirect_uri?: string | ||
| redirect?: boolean | ||
| message?: string |
There was a problem hiding this comment.
Sending the raw query string to preserve the HMAC signature is the right call. But if the browser ever normalizes or re-encodes query params (e.g. special characters, unicode), the HMAC will fail. The invalid_signature handling below (line 99) covers this — good.
|
|
||
| // This worker's public origin. Prefer the explicit MCP_URL binding (proxy hops can drop the | ||
| // Host header); fall back to the request host, then the prod custom domain. | ||
| const mcpBaseUrl = (c: Context<{ Bindings: Bindings }>): string => { |
There was a problem hiding this comment.
mcpBaseUrl falls back to x-forwarded-host / host headers when MCP_URL is not set. Since this value ends up in the resource field of the OAuth protected resource metadata (line 74), a spoofed x-forwarded-host could cause MCP clients to send tokens to the wrong resource. The MCP_URL env var mitigates this in production, but in dev mode without it set, this is exploitable. Consider only using host (not x-forwarded-host) as the fallback, since CF Workers set host reliably.
| p.delete("redirect") | ||
| p.delete("error") | ||
| return `${backend}/api/auth/mcp/authorize?${p.toString()}` | ||
| return `${backend}/api/auth/oauth2/authorize?${p.toString()}` |
There was a problem hiding this comment.
Endpoint changed from /api/auth/mcp/authorize to /api/auth/oauth2/authorize. This must be deployed simultaneously with mono PR #1552 — if this PR lands first, the login page will redirect to a non-existent endpoint. If #1552 lands first, the old endpoint is removed and existing login pages break. Coordinate the deployment.
| "vars": { | ||
| "API_URL": "https://api.supermemory.ai" | ||
| "API_URL": "https://api.supermemory.ai", | ||
| "MCP_URL": "https://mcp.supermemory.ai" |
There was a problem hiding this comment.
The MCP_URL var is set to https://mcp.supermemory.ai here but the resource field in the mono API's /.well-known/oauth-protected-resource (PR #1552, well-known.ts) uses BETTER_AUTH_URL (i.e. https://api.supermemory.ai). These are intentionally different resources, but make sure the oauthValidAudiences in mono PR #1552 includes the MCP origin — it does via mcpServerUrl(env), so this should be fine.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub. |
Show the requesting plugin's icon + 'Connect <Name>' on the OAuth consent page so users see exactly which first-party plugin (Claude Code, OpenCode, OpenClaw, OpenAI Codex) is asking for access. Falls back to a generic 'An application wants to connect' for unknown/DCR-registered clients. KNOWN_OAUTH_CLIENTS mirrors mono/packages/lib/plugins.ts; the two repos don't share a package, so kept in sync manually (follow-up: shared lib). Also add a 'codex' entry to PLUGIN_INFO in app/auth/connect/page.tsx for the legacy sm_ key flow path (Codex CLI plugin).
|
Warning Review the following alerts detected in dependencies. According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.
|
No description provided.