如何在Composer中配置私有认证？auth.json文件的安全管理-composer-PHP中文网

私有包认证必须用auth.json，绝不能写进composer.json；文件放错路径、权限不对、域名不匹配是401错误三大主因：项目根目录（最高优先级）→$composer_home/auth.json（linux/macos需chmod 600）→composer_auth环境变量（json字符串，优先级最高）。

如何在composer中配置私有认证？auth.json文件的安全管理

直接结论：私有包认证必须用 auth.json，绝不能写进 composer.json；文件放错路径、权限不对、域名不匹配，是 401 错误的三大主因。

auth.json 放哪才真正生效？

Composer 查找 auth.json 有严格顺序，找到第一个就停，不会合并：

项目根目录（和 composer.json 同级）→ 仅影响当前项目，适合不同项目用不同 token 的场景
$COMPOSER_HOME/auth.json（Linux/macOS 是 ~/.composer/auth.json 或 ~/.config/composer/auth.json；Windows 是 %APPDATA%\Composer\auth.json）→ 全局生效，但 Linux/macOS 下权限必须 ≤600（chmod 600 auth.json），否则静默忽略
COMPOSER_AUTH 环境变量 → 优先级最高，适合 CI/CD，值是 JSON 字符串，例如：{"http-basic":{"repo.example.com":{"username":"token","password":"xxx"}}}

常见错误：把 auth.json 放进 vendor/、src/ 或子目录，Composer 完全不读；在 Docker 或 CI 中误以为写进项目根目录就能全局生效——其实只对当前项目起作用。

怎么写才不报 401？域名和字段名必须精确

HTTP 401 几乎从不是密码错了，而是凭据根本没被送到目标主机。关键点：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

域名必须和仓库 URL 的主机名**完全一致**：比如 https://pkg.internal.company:8080/v2 → auth.json 里 key 得是 "pkg.internal.company:8080"；https://gitlab.example.org/api/v4/... → key 是 "gitlab.example.org"，不能带协议、路径或 www.
http-basic 是顶层键，子对象里只能是 username 和 password 字段，拼成 user、passwd、api_token 都无效
GitHub 私有包必须用 github-oauth 段，key 固定为 "github.com"（哪怕你用 GitHub Enterprise，也得填实际域名如 "ghe.example.com"），token 填在值里，不能放 http-basic 下
Nexus、Artifactory 等私仓常要求 username 填 token、password 留空——这不是配置错，是它们的实现方式

别手动编辑，用 `composer config` 命令生成

手动写 JSON 容易多逗号、少引号、权限错、历史泄露密码。推荐命令行方式：

项目级（写入当前目录 auth.json）：composer config http-basic.repo.example.com deploy 'p@ss$w!rd'（密码含 shell 特殊字符必须单引号包裹）
全局级（写入 $COMPOSER_HOME/auth.json）：composer config --global http-basic.repo.example.com deploy abc123
验证是否写入成功：composer config --list | grep http-basic（项目级）或 composer config --global --list | grep http-basic（全局级）

该命令自动处理 JSON 格式、base64 编码逻辑，且不把密码留在 shell 历史中。注意：github-oauth 不支持命令行交互式录入，仍需手动编辑 auth.json 添加。

CI/CD 中怎么安全传 token？

硬编码、提交 auth.json、用 composer config 动态写文件，都存在泄露风险。正确做法：

用 COMPOSER_AUTH 环境变量注入，值为合法 JSON 字符串，优先级高于所有本地文件
GitHub Actions 中设为 secret：COMPOSER_AUTH: ${{ secrets.COMPOSER_AUTH }}，secret 内容就是 {"http-basic":{...}}
GitLab CI 若用 vcs 类型仓库（如 "type": "vcs", "url": "https://gitlab.example.com/group/pkg.git"），仅 http-basic 不够——git clone 阶段走的是 git 命令，需额外配 git_source 模板或用 before_script 替换占位符
Token 权限最小化：GitHub PAT 至少勾选 read:packages；GitLab token 至少含 read_api；定期轮换，不用个人长期 token

最易被忽略的一点：很多团队在 CI 中用了 composer install，却忘了清理 vendor/ 或缓存，导致旧凭据残留；或者 Nginx 反向代理没透传 Authorization 头，请求根本没带认证信息——这些地方查不到 auth.json 配置本身的问题，但结果一样是 401。