Support authentication for private `--dist-url` Node.js distribution mirrors
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 48/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- javascript, nodejs
调研方向
从 node-gyp 的集中式下载辅助函数以及构造请求标头的位置开始。跟踪 headers tarball、SHASUMS256.txt 和 Windows node.lib 的请求,然后查看相关 issue,了解现有约束。完成的标准是:一种有文档记录的身份验证方案能够一致地应用,同时不会泄露凭据,也不会将凭据转发到已配置的分发范围之外。
由索引模型根据 Issue 内容生成。
描述
Observed in node-gyp@12.4.0
node-gyp supports custom Node.js distribution mirrors via --dist-url / node_gyp_dist_url, but there does not appear to be a documented way to authenticate requests made to that mirror.
This is a problem in corporate environments where Node.js distributions and headers are served through an authenticated Artifactory mirror.
Example failure
gyp http GET https://artifactory.example.com/artifactory/nodejs-dist/v24.19.0/node-v24.19.0-headers.tar.gz
gyp http 401 https://artifactory.example.com/artifactory/nodejs-dist/v24.19.0/node-v24.19.0-headers.tar.gz
Package installation itself works because npm, pnpm, or Yarn can authenticate against the package registry. The failure happens later, when node-gyp downloads Node.js headers from the configured distribution URL.
Example package registry authentication:
registry=https://artifactory.example.com/artifactory/api/npm/npm-virtual/
//artifactory.example.com/artifactory/api/npm/npm-virtual/:_authToken=${NPM_TOKEN}
Example Node.js distribution mirror:
https://artifactory.example.com/artifactory/nodejs-dist/
Example node-gyp configuration:
npm_package_config_node_gyp_dist_url=https://artifactory.example.com/artifactory/nodejs-dist
Expected behavior
When --dist-url / node_gyp_dist_url points to an authenticated mirror, node-gyp should provide a supported way to authenticate downloads from that mirror.
Authentication would need to apply consistently to:
- the Node.js headers tarball;
SHASUMS256.txt;- Windows
node.libfiles; - any other files downloaded from the configured distribution URL.
Possible solutions
Any of the following would solve the issue. Explicit node-gyp configuration may be preferable given npm's move away from unsupported custom .npmrc keys.
1. Add explicit node-gyp authentication configuration
For example:
node-gyp rebuild \
--dist-url=https://artifactory.example.com/artifactory/nodejs-dist \
--dist-url-auth-token="$NODE_GYP_DIST_TOKEN"
Or through lifecycle-safe configuration:
npm_package_config_node_gyp_dist_url_auth_token=$NODE_GYP_DIST_TOKEN
The option name could be adjusted to match the project's preferred naming and credential model.
2. Support an explicit authentication-header option
For example:
node-gyp rebuild \
--dist-url=https://artifactory.example.com/artifactory/nodejs-dist \
--dist-url-auth-header="Authorization: Bearer $NODE_GYP_DIST_TOKEN"
A credential-specific option may be safer than accepting arbitrary headers, but some environments require non-standard authentication headers.
3. Optionally support npm-compatible URL-scoped authentication
For example:
//artifactory.example.com/artifactory/nodejs-dist/:_authToken=${NODE_GYP_DIST_TOKEN}
This should only be considered if it can be implemented as documented, supported node-gyp behavior rather than relying on arbitrary unsupported .npmrc keys.
Implementation context
The downloads appear to be centralized through node-gyp's download helper. The headers tarball, checksum file, and Windows node.lib requests all use the same download path, where request headers are currently constructed.
This seems like a relatively contained integration point: authentication could be resolved once for the configured dist-url and applied to all requests made within that distribution scope.
Security considerations
- Credentials should only be sent to URLs under the configured
dist-url. - Credentials must not be logged, including with verbose or silly logging.
- Credentials should not be forwarded across redirects to a different host.
- Environment-variable-based configuration should be supported so secrets do not need to be committed.
- Authentication should be applied consistently to the tarball, checksum, and
node.librequests. - If npm-compatible credentials are supported, matching should respect the configured URL scope rather than sending credentials to every URL on the same host.
- Credentials should not appear in error messages, generated files, or process arguments where avoidable.
Current workarounds
There are partial workarounds, but they are difficult to apply reliably in package-manager-driven installs:
--nodedirrequires a compatible local Node.js headers/source tree and a way to pass the option to the actual transitivenode-gypinvocation.--tarballcan avoid network access, but it requires invokingnode-gyp installexplicitly before the dependency rebuild.- Manually pre-populating node-gyp's cache is brittle because the cache must match node-gyp's expected layout and metadata, including
installVersion. - Embedding credentials in
--dist-urlonly works when the mirror accepts Basic Auth and may expose credentials in logs or process arguments.
In practice, these workarounds are difficult to standardize across developer machines and CI systems when native modules invoke node-gyp indirectly during installation or bootstrapping.
Related issues
This appears related to:
- #1287 — private Artifactory/mirror header download problems;
- #3000 — node-gyp downloading headers despite a local cache.
Question
Would maintainers be open to supporting authentication for private --dist-url mirrors?
If so, would URL-scoped npm-compatible authentication or explicit node-gyp-specific authentication options be preferred?
- 主要语言
- Python
- 星标
- 10.7k
- 派生
- 1.9k
- 平均合并
- 1 天 4 小时
- 30 天内合并 PR
- 5
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
nodejs/node-gyp 的其他 Issue
-
dependencies github_actions
难度 2/5 1-3 小时 新手友好度 68/100
-
难度 4/5 3-5 天 新手友好度 48/100
-
MSYS2
难度 4/5 3-5 天 新手友好度 35/100
-
难度 4/5 3-5 天 新手友好度 48/100
-
难度 5/5 一周以上 新手友好度 10/100
相似的 Issue
-
bug confirmed issue
难度 2/5 1-3 小时 新手友好度 75/100
open-webui/open-webui#30750 · 1 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
-
enhancement
难度 2/5 1-3 小时 新手友好度 75/100
OpenwaterHealth/openmotion-bloodflow-app#604 · 1 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 70/100
-
good first issue
难度 1/5 1 小时以内 新手友好度 90/100