开发工具CLI包管理器任务调度【免费下载链接】pixiPowerful system-level package manager for Linux, macOS and Windows written in Rust – building on top of the Conda ecosystem.项目地址https://gitcode.com/gh_mirrors/pi/pixi点击查看免费下载pixi auth login是 pixi 包管理器中用于保存某个主机host认证信息的核心命令无论是登录 prefix.dev 获取私有渠道访问权、为 anaconda.org / quetz 配置 conda token、为自建渠道配置 Basic HTTP 认证还是为 S3 兼容存储桶配置密钥都可以通过这一条命令完成。读完本文你将掌握该命令的全部参数与四种认证方式的适用场景理解凭据的底层存储机制系统钥匙串 / 回退 JSON 文件并能结合仓库源码看懂 pixi 与底层 rattler 生态如何消费这些凭据。本文以仓库中的命令参考文档 docs/reference/cli/pixi/auth/login.md 为主体并参考 docs/deployment/authentication.md 与相关 Rust 源码展开。命令概览与基本语法pixi auth login的作用一句话概括为指定主机存储认证信息供后续所有需要访问该主机的 pixi 操作pixi install、pixi upload、pixi publish等自动复用。其基本语法为pixi auth login [OPTIONS] HOST必选参数HOST参数说明HOST要认证的主机例如prefix.dev。必填HOST 的写法随认证方式不同而变化普通 HTTP 服务直接写域名如prefix.dev、myserver.comS3 存储桶则以s3://协议开头如s3://my-bucket。通用选项--user-agent选项说明--user-agent USER_AGENT设置请求中携带的User-Agent请求头某些自建渠道或代理服务会校验 User-Agent通过该选项可以覆盖默认值用于满足服务端对客户端的识别要求。四种认证方式与完整参数说明pixi auth login将参数按认证方式划分为三组OAuth/OIDC、S3、Token/Basic。不同服务器使用不同的认证方法实际选择取决于目标主机支持哪种协议。OAuth/OIDC 认证OAuth/OIDC 是 pixi 向 prefix.dev 等现代渠道推荐的首选方式适合交互式桌面环境选项说明--oauth启用 OAuth/OIDC 认证流程--oauth-issuer-url OAUTH_ISSUER_URLOIDC 发行方issuerURL默认取https://{host}--oauth-client-id OAUTH_CLIENT_IDOAuth 客户端 ID默认值为rattler--oauth-client-secret OAUTH_CLIENT_SECRETOAuth 客户端密钥仅用于机密型客户端 confidential client--oauth-flow OAUTH_FLOW认证流程device-code、auth-code、auto见下方说明--oauth-scope OAUTH_SCOPES额外请求的 OAuth scope可重复指定--oauth-redirect-uri OAUTH_REDIRECT_URIOAuth 回调 URI默认使用随机 localhost 端口当 IdP 侧注册了固定回调地址时需显式设置例如http://127.0.0.1:8000/auth/oidc关于--oauth-flow的默认值命令参考文档 login.md 记录为device-code而 docs/deployment/authentication.md 中的帮助输出显示默认值为auto三选一auto、auth-code、device-code。从后者的说明看auto会在运行时自动抉择Authorization Code with PKCE当处于带可用浏览器的桌面环境时pixi 会打开浏览器标签页你在服务端完成登录后由本地回调页完成令牌交换Device Code当 pixi 无法为你打开浏览器SSH 会话、无头服务器、容器 shell 等时pixi 打印一个短用户码和 URL你在任意设备上打开 URL 并输入该码即可完成认证。如果auto的选择与你的环境不符可以强制指定某一流程例如无浏览器环境pixi auth login prefix.dev --oauth-flow device-code最简登录方式对 prefix.devpixi auth login prefix.dev该命令会打开浏览器标签页登录 prefix.dev 后 pixi 将凭据存入系统钥匙串。此登录授予的权限覆盖访问个人资料、读取渠道以及上传包足以让pixi install、pixi upload、pixi publish开箱即用令牌在过期前 pixi 会在后台自动刷新。对于自带 OIDC 的自建主机pixi 未内置默认参数需要显式传入全部配置pixi auth login my.private.host \ --oauth \ --oauth-issuer-url https://idp.example.com \ --oauth-client-id my-cli-client \ --oauth-scope openid --oauth-scope channel:readToken 认证Bearer Token如果你希望自行管理令牌例如 CI 场景无法进行浏览器登录可以使用标准 Bearer Token 认证pixi auth login prefix.dev --token pfx_jj8WDzvnuTHEGdAhwRZMC1Ag8gSto8选项说明--token TOKEN用于认证的令牌例如 prefix.dev 的 tokenBearer Token 会以Authorization: Bearer TOKEN请求头随每次请求发送。token 认证适合在 CI、脚本等自动化环境中注入预先签发好的长期令牌。anaconda.org / quetz 的 conda tokenpixi auth login anaconda.org --conda-token xy-72b914cc-c105-4ec7-a969-ab21d23480ed选项说明--conda-token CONDA_TOKEN用于 anaconda.org / quetz 认证的 tokenConda token 的特别之处在于它被嵌入 URL 路径中conda.anaconda.org/t/TOKEN/conda-forge/linux-64/...。quetz 服务器同样接受该 scheme因此自建 quetz 实例也可以用--conda-token登录。Basic HTTP 认证pixi auth login myserver.com --username user --password password选项说明--username USERNAMEBasic HTTP 认证的用户名--password PASSWORDBasic HTTP 认证的密码这等价于http://user:passwordmyserver.com/...的访问方式是自建渠道部署在 NGINX/Apache 反向代理之后并启用 HTTP Basic 认证时的典型选择。S3 认证pixi 支持对 S3 兼容存储桶进行认证例如将包上传到 S3 或从 S3 渠道读取 repodatapixi auth login s3://my-bucket --s3-access-key-id access-key-id --s3-secret-access-key secret-access-key # 若密钥包含会话令牌还可以追加 pixi auth login s3://my-bucket --s3-access-key-id access-key-id --s3-secret-access-key secret-access-key --s3-session-token session-token选项说明--s3-access-key-id S3_ACCESS_KEY_IDS3 访问密钥 ID--s3-secret-access-key S3_SECRET_ACCESS_KEYS3 秘密访问密钥--s3-session-token S3_SESSION_TOKENS3 会话令牌临时凭据场景需要注意登录 S3 时 HOST 要写成s3://my-bucket这样的 URI 形式。此外S3 认证也支持通过 AWS 标准环境变量AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY进行详见 docs/deployment/s3.md。完整示例速查以下示例来自命令文档的示例扩展 login_extender覆盖了全部认证方式的典型用法# OAuth 登录 prefix.dev pixi auth login prefix.dev # OAuth 登录自建 OIDC 提供商 pixi auth login my.private.host \ --oauth \ --oauth-issuer-url https://idp.example.com \ --oauth-client-id my-cli-client # 无浏览器机器强制 device-code 流程 pixi auth login prefix.dev --oauth-flow device-code # 手动 token、conda token、basic auth、S3 凭据 pixi auth login repo.prefix.dev --token pfx_JQEV-m_2bdz-D8NSyRSaAndHANx0qHjq7f2iD pixi auth login anaconda.org --conda-token ABCDEFGHIJKLMNOP pixi auth login https://myquetz.server --username john --password xxxxxx pixi auth login s3://my-bucket --s3-access-key-id $AWS_ACCESS_KEY_ID --s3-secret-access-key $AWS_SECRET_ACCESS_KEY凭据存储在哪里认证信息由 pixi 底层使用的 rattler 网络库负责持久化存储位置随操作系统不同而不同来自 docs/deployment/authentication.mdWindows存储在凭据管理器Credentials Manager中搜索rattler即可找到 pixi或其他基于 rattler 的程序保存的凭据macOS存储在钥匙串Keychain中可用系统自带的Keychain Access程序访问同样搜索rattlerLinux使用GNOME Keyring或 Keyring经由libsecret安全存储搜索rattler可列出全部相关凭据。回退存储JSON 文件如果运行环境没有任何上述钥匙串可用例如精简服务器pixi 会回退到不加密的 JSON 文件存储凭据该文件位于~/.rattler/credentials.json。虽然不加密但它保证在无钥匙串环境下认证功能依然可用。覆盖存储位置你可以通过RATTLER_AUTH_FILE环境变量覆盖默认凭据文件位置。设置后该文件将成为 pixi 唯一使用的认证数据来源export RATTLER_AUTH_FILE$HOME/credentials.json # 也可以在命令行指定 pixi global install --auth-file $HOME/credentials.json ...注意RATTLER_AUTH_FILE的优先级高于命令行参数。该文件的 JSON 格式如下{ *.prefix.dev: { BearerToken: your_token }, otherhost.com: { BasicHTTP: { username: your_username, password: your_password } }, conda.anaconda.org: { CondaToken: your_token }, s3://my-bucket: { S3Credentials: { access_key_id: my-access-key-id, secret_access_key: my-secret-access-key, session_token: null } } }JSON 中的主机名支持通配符若使用*.prefix.dev则任何子域都会匹配例如repo.prefix.dev也匹配。此外还可以在全局配置文件中设置认证覆盖文件详见 docs/reference/pixi_configuration.md。源码视角pixi 如何组织与消费认证pixi auth这一组命令login / logout / token / status在 pixi CLI 中通过 rattler 生态的 CLI 实现接入。在 crates/pixi_cli/src/lib.rs 中可以看到Auth(rattler::cli::auth::Args)的声明并在命令分发处crates/pixi_cli/src/lib.rs直接调用rattler::cli::auth::execute执行——这正是pixi auth login各项参数与 OAuth/S3 流程的底层实现来源。而 pixi 自身负责的是依据配置构造统一的认证存储AuthenticationStorage。这一逻辑集中在 crates/pixi_auth/src/lib.rsget_auth_storecrates/pixi_auth/src/lib.rs首先从环境变量与默认后端构造存储AuthenticationStorage::from_env_and_defaults()随后检查 pixi 配置中的authentication_override_file设置将文件型存储按优先级插入后端列表排在RATTLER_AUTH_FILE之后、钥匙串之前get_auth_middlewarecrates/pixi_auth/src/lib.rs将认证存储包装为AuthenticationMiddleware供 HTTP 请求中间件链直接使用。该存储被多个上层命令消费上传crates/pixi_cli/src/upload.rs 中pixi upload通过get_auth_store获得认证存储并传递给 rattler 的上传选项从而复用pixi auth login保存的凭据发布crates/pixi_cli/src/publish/mod.rs 在发布流程的上下文PublishContext中持有auth_storage用于上传到 prefix、anaconda、cloudsmith、quetz、artifactory 等目标其中 S3 场景会从认证存储解析凭据若未找到会提示用户运行pixi auth login s3://{bucket}来保存凭据见 crates/pixi_cli/src/publish/mod.rs状态查看crates/pixi_cli/src/info.rs 的pixi info会显示认证存储位置其优先级为RATTLER_AUTH_FILE环境变量 → 全局配置的authentication_override_file→ 默认文件型存储。与其他 auth 子命令配合使用pixi auth login是 pixi auth 子命令组的一员与之配套的还有pixi auth logout移除指定主机的认证信息pixi auth token打印指定主机已存储的认证令牌pixi auth status显示已存储的认证条目及非机密令牌元数据。典型工作流是先用pixi auth login写入凭据日常使用pixi install/pixi upload/pixi publish自动复用需要排查或清理时用pixi auth status/pixi auth logout管理在 CI 等无钥匙串环境则通过RATTLER_AUTH_FILE或--token直接注入预先准备的凭据文件实现完全非交互的认证。赞分享开发工具CLI包管理器任务调度【免费下载链接】pixiPowerful system-level package manager for Linux, macOS and Windows written in Rust – building on top of the Conda ecosystem.项目地址https://gitcode.com/gh_mirrors/pi/pixi点击查看免费下载相关推荐pixi 使用 S3 对象存储作为 Conda 频道认证、配置与上传全指南pixi 使用 S3 对象存储作为 Conda 频道认证、配置与上传全指南 导读 本文围绕 pixi 如何将 AWS S3以及各类 S3 兼容存储作为 C开发工具CLI包管理器任务调度req认证机制全攻略Basic Auth、Bearer Token和Digest Auth终极指南req认证机制全攻略Basic Auth、Bearer Token和Digest Auth终极指南 req作为一款Simple Go HTTP client网络通信ToolJet REST API 数据源认证配置指南Basic、Bearer Token 与 OAuth 2.0 全解析ToolJet REST API 数据源认证配置指南Basic、Bearer Token 与 OAuth 2.0 全解析 本指南以 ToolJet 官方文档低代码后端前端AI 应用MCP 服务上一篇PTO-ISA MoE Dispatch算子下一篇如何用Playnite终极解决游戏库碎片化3个场景2个方案实现高效统一管理创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
