fix(connectors): auto-prepend Bearer prefix for header-auth MCP connectors - #492
fix(connectors): auto-prepend Bearer prefix for header-auth MCP connectors#492kristopolous wants to merge 1 commit into
Conversation
🦋 Changeset detectedLatest commit: 4e5d13f The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Screenshots — superseded, see the PR description above(This comment tracked two earlier approaches — auto-detect-and-silently-prepend, then a checkbox. The PR now uses a third approach: live-probing the upstream server with each candidate and reporting progress in the dialog. Current screenshots and rationale are in the PR description at the top of this page.) |
d2a4ec7 to
4f53586
Compare
Bright Data (and any other header-auth MCP connector — GitHub, Tavily,
or a custom one) rejected pasted API keys with 401 because nothing
told the user their key needs a scheme prefix like "Bearer ".
Rather than asking the user to know this up front, the Connect /
Replace Key dialog now tests the pasted key live against the real
upstream server: as typed first, then with "Bearer ", then with
"Basic " (skipping a scheme the raw key already carries), reporting
each attempt inline ("Testing key… failed", "Trying with prefix
"Bearer"… succeeded", …). Whichever candidate actually connects is
what gets stored; if all three fail, the dialog stays open with the
last real error.
Minimal, single-file change (plus its test) — no new types, no catalog
lookups, no server-side change. Reuses the existing create/update +
getToolsByConnectorId calls the UI already had.
Fixes truefoundry#490
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MxyEPwQ73B27NTr83U69Ba
4f53586 to
4e5d13f
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 4e5d13f. Configure here.
| } catch (err) { | ||
| lastError = getErrorMessage(err, 'Connection failed'); | ||
| setProbeLog(log => [...log.slice(0, -1), `${candidate.label} failed`]); | ||
| } |
There was a problem hiding this comment.
Probe retries cannot update new connectors
High Severity
existingConnector is captured once before the probe loop, so first-time Connect always calls createFromCatalog for every candidate. The raw key is persisted on the first attempt; later Bearer/Basic tries then hit a name conflict instead of updating. The working prefix is never stored, the dialog reports failure, and a connector remains saved with the rejected key.
Reviewed by Cursor Bugbot for commit 4e5d13f. Configure here.


Summary
Fixes #490.
Bright Data (and any other header-auth MCP connector — GitHub, Tavily, or a custom one added via "Add MCP Server") rejected pasted API keys with
401 Unauthorizedbecause nothing told the user their key needs a scheme prefix likeBearer.Rather than requiring the user to know this up front (an earlier version of this PR used a checkbox for that), the Connect / Replace Key dialog now tests the pasted key live against the real upstream server: as typed first, then with
Bearer, then withBasic(skipping a scheme the raw key already carries), reporting each attempt inline in the dialog — e.g.Testing key… failed,Trying with prefix "Bearer"… succeeded. Whichever candidate actually connects is what gets stored. If all three fail, the dialog stays open with the last real error message so the user isn't left guessing.Minimal, single-file change (
packages/trueforge-ui/src/containers/SettingsBuilder/ConnectorSettings.tsx, plus its test) — no new types, no catalog-template lookups, no server-side change. It reuses the create/update-connector andgetToolsByConnectorIdcalls the UI already had; the only new piece is the retry loop and the inline log.Test plan
ConnectorSettings.test.tsx(5 tests): stores the raw key when it works first try; falls back toBearer; falls back toBasic; shows a final error and keeps the dialog open when everything fails (and logs every attempt); doesn't double-prefix a key already typed withBearer.pnpm vitest runinpackages/trueforge-ui— 870/870 pass.pnpm tsc --noEmit(src + test) — clean.pnpm eslinton changed files — clean.@truefoundry/trueforge-uipatch).mcp.brightdata.comfor all three attempts, not mocked.Screenshots (local run against the real app, live network calls to Bright Data)
1. The Connect dialog, unchanged in shape:

2. Mid-probe — the dialog reports each attempt as it happens:

3. All three attempts logged, real error surfaced, dialog stays open for a retry (this fake key genuinely fails everywhere — the log is the point, not the failure):

(Screenshots hosted on an orphan
pr-492-screenshots-v3branch on my fork, not merged into this PR's diff. The success path — storing whichever prefix actually connects — is covered by the unit tests, since it requires a real upstream credential to demo live.)🤖 Generated with Claude Code
https://claude.ai/code/session_01MxyEPwQ73B27NTr83U69Ba