Composer企业级包管理器私有授权证书的自动化分发与更新-composer-PHP中文网

composer 不提供私有授权证书的自动化分发与更新能力，仅读取 auth.json 中的 ssh 密钥、bearer token 或 oauth2 token 用于访问私有仓库，且凭据需手动维护或由外部流程写入，不支持自动续期。

composer企业级包管理器私有授权证书的自动化分发与更新

Composer 本身不提供私有授权证书的自动化分发与更新能力——它压根不处理证书，只读取 auth.json 中的凭据用于访问私有仓库（如 Git、Satis、Private Packagist 或 Artifactory）。所谓“证书”，在 Composer 场景中实际是 SSH 密钥、HTTP Bearer Token 或 OAuth2 token，不是 TLS 证书或 X.509 证书。

auth.json 是唯一生效的凭据载体，但不能自动更新

Composer 只在安装/更新时读取项目根目录或全局 ~/.composer/auth.json（优先级：项目 > 全局）。该文件内容必须手动维护或由外部流程写入：

auth.json 格式必须严格为 JSON，且字段名固定：{"http-basic": {...}, "github-oauth": {...}, "gitlab-token": {...}}
HTTP Basic 凭据（如私有 Satis 或 Nexus）需明文填入 username 和 password，不支持环境变量插值
GitHub/GitLab 的 token 字段名不同（github-oauth vs gitlab-token），填错就 401
凭据过期后，composer install 直接失败，报错类似 Could not fetch https://repo.internal/packages.json, please review your auth config

私有包仓库类型决定凭据分发方式

不同私有仓库对认证机制的支持差异极大，不能一概而论：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

Git 仓库（"type": "vcs"）：依赖 SSH 密钥或 HTTPS + auth.json。密钥需提前部署到 CI/CD agent 或服务器，auth.json 无法自动注入密钥内容
Satis / Private Packagist：仅支持 HTTP Basic，凭据必须硬编码在 auth.json 中，或通过 CI 环境变量注入后生成该文件
Artifactory / Nexus：支持多种方式，但 Composer 只认 http-basic 块；若启用了 API Key 或 JWT，需用反向代理或网关转换为 Basic Auth
自建 Packagist 镜像（如 Toran Proxy 已停更）：已无维护，不建议新项目采用

CI/CD 中安全注入凭据的实操要点

在 GitHub Actions、GitLab CI 或 Jenkins 中，不能把凭据写进代码，也不能让 auth.json 被提交。可靠做法是：

使用 CI 内置 secrets（如 GITHUB_SECRET_COMPOSER_TOKEN）在 job 运行时动态生成 auth.json

示例（GitHub Actions）：

run: |
    echo '{"http-basic": {"repo.internal": {"username": "deploy", "password": "${{ secrets.COMPOSER_PASSWORD }}"}}}' > auth.json

务必在 composer install 前执行 chmod 600 auth.json，避免日志泄露凭据
禁止在 composer.json 中写死 token 或密码；repositories 配置里的 URL 也不应含 credentials（如 https://user:pass@repo.internal）
若用 Docker 构建镜像，不要 COPY auth.json 进镜像层——它会残留于历史记录中；改用 build args + 构建时挂载临时文件