Previously the SSE connection would always default to the
`/.well-known/oauth-protected-resource` URI, ignoring the `resource_metadata`
portion of the `www-authenticate` returned in a 401.
Extract the metadata from the initial 401, so RS servers with
custom protected resource URIs (as in RFC9728, [section 3.1][1]))
continue to work as expected.
[1]: https://datatracker.ietf.org/doc/html/rfc9728#section-3.1
- Remove all console.log, console.warn, and console.error from src/client and src/server
- Add ESLint no-console rule for client and server directories (excluding tests)
- Keep console statements in test files, examples, and CLI tools as intended
Addresses feedback in PR #665🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Fixed 5 instances of hardcoded "https://resource.example.com" in OAuth
protected resource metadata mocks to use the actual resourceBaseUrl.href.
This resolves test failures where the auth validation was rejecting
requests because the resource URL in the metadata didn't match the
actual test server URL.
The failing tests were:
- attempts auth flow on 401 during SSE connection
- attempts auth flow on 401 during POST request
- refreshes expired token during SSE connection
- refreshes expired token during POST request
- redirects to authorization if refresh token flow fails
All SSE tests now pass (17/17).
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Tests that when mcp-protocol-version header is missing, the middleware
uses DEFAULT_NEGOTIATED_PROTOCOL_VERSION when calling verifyAccessToken
- Ensures proper fallback behavior for protocol version negotiation
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
