feat(config): derive every Atlas API call from one overridable origin - #8
Open
binyangzhu000-sudo wants to merge 2 commits into
Open
Conversation
The three Atlas base URLs were hard-coded to production, so a staging deployment authenticated users against staging while calling the production API. Only production API keys worked there, credential validation checked the wrong account universe, and any billable test run charged a real account. Derive all three from a single origin, overridable with ATLASCLOUD_API_BASE_URL and defaulting to production, so an isolated environment can be pointed at its own Atlas without patching call sites. The override is refused outright in a production release. A production plugin quietly talking to a different Atlas is not a failure that announces itself — it surfaces when a customer sees another account's data — so it fails at startup instead. The value must be a bare origin: the API paths are appended to it, and a path here would silently produce /api/v1/api/v1/... Credentials in the URL and plaintext HTTP are rejected, the latter except for loopback so a local Atlas can still be used during development.
Cluster-internal Service DNS (*.svc.cluster.local) never traverses the public network, and demanding TLS there pushes toward the worse fix of publishing internal services behind a public ingress. Public hostnames still require https, and a hostname merely containing the suffix inside a longer public domain stays rejected.
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
1 participant
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.
背景
src/constants.ts把三个 Atlas API 地址写死成生产：后果是 staging 部署在拿生产数据做测试：用户身份由 staging 认证，API 调用却打生产。所以 staging 上只有生产的 API key 能用、凭据校验查的是错的账号库、而任何计费型测试都会扣真实账号的钱。
改了什么
三个地址统一从一个 origin 派生，可用
ATLASCLOUD_API_BASE_URL覆盖，默认仍是生产：几个刻意的约束
/api/v1/api/v1/...。验证
tsc干净，npm test82/82 通过（原 76 + 新增 6）。新增测试覆盖：默认值、合法覆盖、末尾斜杠、loopback 例外、非 loopback http 拒绝、生产覆盖拒绝（含"显式填默认值不算覆盖"）、带 path/query/凭据/非法 URL 的拒绝、以及三个派生地址确实同源。为什么现在需要它
V2（首次登录自动绑定 API key，#4）没法在 dev 验证：dev 插件会去问 dev 的 kubedl 要 key，拿到的却是 dev 库的 key，而插件的校验打的是生产 API，必然失败并回落到手贴。有了这个开关，dev 插件可以整体指向 dev 的 Atlas，形成自洽闭环。
注意：光有这个改动还不够——dev 的 kubedl 目前没有对外 HTTPS 入口（
api.dev.atlascloud.ai/console.dev.atlascloud.ai打/api/v1/health都是 401，只有集群内直连才 200）。要在 dev 端到端验证 V2，还需要给它配一个 ingress。