fix(auth): cover the transport's own discovery, and only rewrite GETs
Two more review findings, both real. The shim wrapped `effectiveAuthFetch` only, but the transport is constructed with the base `this.fetchFn`, and the SDK runs its own discovery from inside the transport on the 401/refresh leg — so a reconnect with an existing auth provider could still hit the upstream failure. It now wraps the base fetch, the same seam `withOAuthEndpointOverrides` uses and the only one that reaches both paths. That trades away the previous claim that a captured Network entry shows the real 404: below the trackers, what they record is the substitution. Rather than leave that silently misleading, a substituted response now carries `x-inspector-oauth-metadata-source` naming the URL its body was actually fetched from — the transport builds its tracker internally, so there is no seam above it to install into instead. An integration test captures the fetch the transport is handed and drives it against a real server, since nothing else proves that wiring. The wrapper also keyed on URL shape alone, but nothing stops an authorization or token endpoint from living under `/.well-known/oauth-authorization-server/`; a POST there returning an ordinary OAuth 4xx would have had its error replaced by a metadata document. Metadata discovery is a GET, so anything else is now left alone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UL9retfvAXRgvi6EWk4SY4 Signed-off-by: cliffhall <cliff@futurescale.com>
This commit is contained in:
parent
1db1b9be1f
commit
28c7a9ff8a
1 changed files with 141 additions and 18 deletions
|
|
@ -795,12 +795,14 @@ export class InspectorClient extends InspectorClientEventTarget {
|
|||
// #2172: recover discovery when a plain OAuth 2.0 authorization server
|
||||
// publishes RFC 8414 metadata at `/.well-known/openid-configuration`, which
|
||||
// the SDK validates as an OpenID provider document and rejects. Wraps the
|
||||
// tracked fetch rather than the base one — the opposite of the overrides
|
||||
// above — so the Network tab records the real 404 and the real probe rather
|
||||
// than the substitution the SDK's parse sees.
|
||||
this.effectiveAuthFetch = withRfc8414OidcCompat(
|
||||
this.buildEffectiveAuthFetch(),
|
||||
);
|
||||
// *base* fetch for the same reason the overrides above do: the SDK also
|
||||
// runs discovery from inside the transport, which is handed `this.fetchFn`
|
||||
// directly, so a reconnect with an existing auth provider would otherwise
|
||||
// still hit the upstream failure. The substituted response is stamped with
|
||||
// `COMPAT_SOURCE_HEADER` so a captured entry names the URL its body came
|
||||
// from rather than appearing to be a 200 from the RFC 8414 path.
|
||||
this.fetchFn = withRfc8414OidcCompat(this.fetchFn);
|
||||
this.effectiveAuthFetch = this.buildEffectiveAuthFetch();
|
||||
|
||||
this.sessionId = options.sessionId;
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue