Repository navigation
fix(mcp): drop X-Glean-Internal-Service header from gateway requests (fixes 403 Forbidden on setup) - #40
Closed
zh-ffmc wants to merge 1 commit into
Closed
fix(mcp): drop X-Glean-Internal-Service header from gateway requests (fixes 403 Forbidden on setup)#40zh-ffmc wants to merge 1 commit into
zh-ffmc wants to merge 1 commit into
Conversation
buildTransport() sends X-Glean-Internal-Service: true on every request to
the public MCP gateway (/mcp/gateway/proxy). Glean's public edge refuses
any external request carrying that internal-service marker with a bare
HTTP 403 before auth, so plugin setup fails before the OAuth sign-in
prompt is ever reached - on every instance.
Reproduced live (plugin 3.4.2 and 3.5.1, affected since the header's
introduction):
POST /mcp/gateway/proxy (MCP initialize, NO header)
-> 401 + Www-Authenticate: Bearer resource_metadata=... (correct)
same POST with X-Glean-Internal-Service: true
-> 403 Forbidden (GCP LB HTML page; no X-Glean-Trace-Id, request
never reaches the Glean app)
same POST with browser User-Agent + the header
-> 403 (User-Agent is irrelevant; the header is the trigger)
Removing only the header restores the full flow against a live instance:
401 -> OAuth discovery (PRM/ASM 200) -> dynamic registration 201 ->
token 200 -> gateway initialize 200 -> tools enabled.
The X-Glean-Gateway-Request-Metadata attribution header is untouched.
Adds a regression test that captures the transport's request headers and
asserts the internal-service marker is absent while gateway metadata
remains (fails before this change, passes after). Full bundle suite:
435/435 green; typecheck clean.
Contributor
|
Thank you for tracking this down. The live reproduction table made the cause clear right away. We're closing this in favor of #41, which fixes the same 403. It also removes |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The Glean plugin fails setup with HTTP 403 Forbidden on every instance, before any sign-in prompt. Users cannot connect at all on 3.4.2 / 3.5.1 (reported on a production instance; plugin logs show
connect.backend-error ... 403 Forbiddenimmediately aftersetup.configured).Cause
buildTransport()inshared/glean/mcp/src/remote-client.tsattachesX-Glean-Internal-Service: "true"to every request it sends to the public MCP gateway (https://<instance>.glean.com/mcp/gateway/proxy). Glean's public edge (GCP LB) refuses any external request carrying that internal-service marker with a bare403 ForbiddenHTML page — noX-Glean-Trace-Id, i.e. the request never reaches the Glean app, and the OAuth flow never starts.Live reproduction against a real instance (identical MCP
initializePOST):401+Www-Authenticate: Bearer resource_metadata=...(correct auth challenge)X-Glean-Internal-Service: true403 Forbidden(edge HTML page)403(User-Agent is irrelevant — the header is the trigger)X-Glean-Gateway-Request-Metadataonly401(attribution header is fine)Fix
Remove the header from
buildTransport()and leave a comment so it isn't re-added. Attribution viaX-Glean-Gateway-Request-Metadatais untouched. Verified end-to-end against a live instance with the patched bundle:401 → PRM/ASM discovery 200 → /oauth/register 201 → /oauth/token 200 → gateway initialize 200, setup completes and all remote tools list.Tests
New regression test captures the transport's outgoing request headers (same fetch-bridge pattern as the existing elicitation test) and asserts the internal-service marker is absent while gateway metadata remains. Proven failing before the source change, passing after. Full bundle suite: 435/435 passed,
typecheck:bundleclean.If this header is required for some internal (non-public-ingress) path, the correct home for it is a host-internal build flag — sending it from the public client is what's broken today.