fix(auth): accept BRIGHTDATA_API_TOKEN / API_TOKEN as API-key fallbacks#17
Open
danishashko wants to merge 1 commit into
Open
fix(auth): accept BRIGHTDATA_API_TOKEN / API_TOKEN as API-key fallbacks#17danishashko wants to merge 1 commit into
danishashko wants to merge 1 commit into
Conversation
resolve_api_key only read BRIGHTDATA_API_KEY, but the Bright Data MCP and reference SDKs export the same secret as BRIGHTDATA_API_TOKEN, and the CLI's own add-mcp writes API_TOKEN into the MCP configs it generates. Anyone driving the CLI from that environment hit "No API key found" on the very first call. Fall back BRIGHTDATA_API_KEY -> BRIGHTDATA_API_TOKEN -> API_TOKEN, precedence preserved, empty strings ignored. Update the no-key error message to match, add resolve_api_key coverage, and harden the add-mcp test to clear all three vars so it stays hermetic regardless of the caller's environment.
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
resolve_api_key(src/utils/config.ts) only readBRIGHTDATA_API_KEY. But the Bright Data MCP and the reference SDKs export the same secret asBRIGHTDATA_API_TOKEN, and this CLI's ownadd-mcpcommand writes the key into the generated MCP config asAPI_TOKEN. So anyone driving the CLI from that same environment (an agent, or a developer who set up the MCP) hitsNo API key foundon the very first call.Fix
Fall back
BRIGHTDATA_API_KEY→BRIGHTDATA_API_TOKEN→API_TOKEN. Precedence is preserved (an explicit--api-keyandBRIGHTDATA_API_KEYstill win), and empty-string env vars are ignored, matching the previous behaviour. The "No API key found" message is updated to mention the accepted variables.Tests
resolve_api_keycases: fallback order, precedence, empty-string handling, and the undefined case.add-mcptest to clear all three vars in setup so it stays hermetic regardless of the caller's environment (it previously cleared onlyBRIGHTDATA_API_KEY).Verified:
tscclean, full test suite passes with no new failures, and the built binary authenticates against the live API with onlyBRIGHTDATA_API_TOKENset.