You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(client): preserve resource_metadata URL across non-Bearer WWW-Authenticate challenges
When WWW-Authenticate carries a non-Bearer scheme (e.g. Negotiate),
extractWWWAuthenticateParams returns undefined for resourceMetadataUrl.
Both transports were unconditionally writing that undefined back to
_resourceMetadataUrl, wiping out any URL stored from an earlier Bearer
challenge and breaking PRM discovery for multi-challenge sequences.
- Add optional resourceMetadataUrl to UnauthorizedContext so transports
can pass the stored Bearer URL into the onUnauthorized callback
- handleOAuthUnauthorized now uses extractedUrl ?? ctx.resourceMetadataUrl,
falling back to the stored URL when the current challenge has none
- Both StreamableHTTPClientTransport and SSEClientTransport guard
_resourceMetadataUrl and _scope updates to only overwrite when the
extracted value is non-undefined, and include this._resourceMetadataUrl
in every onUnauthorized context
Fixes#1946
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Fixed OAuth discovery fall back to well-known URI when WWW-Authenticate carries a non-Bearer scheme (e.g. Negotiate). Previously a non-Bearer challenge could clear the `resource_metadata` URL stored from an earlier Bearer challenge, causing PRM discovery to start from the wrong endpoint. The stored URL is now preserved across non-Bearer 401s and passed through to the authorization handler via context.
0 commit comments