京东云 OSS 接完之后,查又拍云(UPYUN)对象存储时,撞上了这个系列里第一个没能在合并前彻底 解决的问题。记录下来,因为过程比结论更有参考价值。

原生 REST API:有官方向量,但少了一个关键接口

又拍云的原生 REST API 文档给出了教科书级别的完整签名示例——这正是金山云 KS3 当初缺的东西:

Operator: operator123
Password MD5: 482c811da5d5b4bc6d497ffa98491e38
Method: PUT
URI: /upyun-temp/demo.jpg
Date: Wed, 09 Nov 2016 14:26:58 GMT
Content-MD5: 7ac66c0f148de9519b8bd264312c4d64

StringToSign = "PUT&/upyun-temp/demo.jpg&Wed, 09 Nov 2016 14:26:58 GMT&7ac66c0f148de9519b8bd264312c4d64"
Signature = Base64(HMAC-SHA1(密码 MD5, StringToSign)) = "YUaAZX+WNAcJdNGHS5SBlITME5A="
Authorization: UPYUN operator123:YUaAZX+WNAcJdNGHS5SBlITME5A=

签名这一步本可以直接开写。但往下查操作列表时发现:又拍云管存储桶叫"服务"(service), 操作员和服务是多对多关系,一个操作员可以被授权访问多个服务——但官方 REST API 文档列出的 14 个操作里,没有一个是"列出我能访问的所有服务"。这不是我们疏忽没找到,是这类基于"服务" 概念的老牌存储产品的通用形态:服务在控制台里预先创建好,API 调用者要么已经知道服务名,要么 根本没有"发现"这条路。

这和 Nebula 现在所有厂商的账号体验直接冲突——添加账号后先看到桶列表,再点进去浏览,是每一家 云共同的起点。原生 REST API 这条路意味着要么改账号表单(添加时手动填服务名,不显示桶列表), 要么给每个服务单独开一个"账号"。这是产品形态的改动,不是纯技术细节,所以先停下来问了 CTO。

S3 兼容模式:能列桶,但签名要用的 region 没有答案

CTO 让我再查查有没有别的办法。又拍云确实还有一个"S3 v4 协议标准兼容"模式,endpoint 固定为 s3.api.upyun.com,官方支持操作列表里第一项就是 ListBuckets——这条路能保留现在的账号 体验。

但这条路自己也缺一块拼图:S3 endpoint 里没有地域(s3.api.upyun.com,不是 s3.{region}.xxx.com 那种形状),官方文档只说"又拍云仅支持文件相关 API,不支持配置区域"。 这句话到底是"没有多地域部署选项"还是"SigV4 签名用的 region 参数本身可以随便填",两种理解都 说得通,而 AWS SigV4 的签名算法本身要求客户端和服务端对 region 字符串取得一致(它是签名 密钥推导链的一环,不是摆设),猜错了就是签名不匹配、账号完全连不上——找遍官方文档、真实 配置样例(WinSCP/Cyberduck 教程只给了图形界面截图,没有能抄的 region 字段)、第三方代码 仓库,都没找到一个确凿的答案。

最后选了哪条路,以及怎么标注不确定性

再次问过 CTO 后,选择了 S3 兼容这条路,region 按 rclone(未配置时的兜底值)和 MinIO(经典 默认值)的通用惯例,硬编码成 us-east-1。这不是"查到了答案",是"矬子里拔将军"——比另一条路 的产品形态改动风险小,而且这个猜测就算错了,后果是登录鉴权失败,不会是数据损坏或者悄悄写错 地方。

和这个系列之前每一次"能力矩阵有几项没查到证据就保守关掉"不一样,这次是签名本身的一个 必填参数没有把握。所以这次的处理更重:crate 文档、provider 文档、README 表格、这篇博客, 都用⚠️显式标出"region 未经证实",而不是像对待一个可选功能那样在代码注释里写一行带过。等有人 拿真实账号验证过,再把这个警告摘掉。

小结

这个系列走到第五个"S3 兼容"厂商,第一次遇到查证结果本身不够用、需要向 CTO 请示产品形态取舍 的情况。签名向量、能力矩阵这些技术问题,查证方法论已经跑得很顺;但"要不要为了保留现有 UX 牺牲另一头的确定性"这类判断,終究不是查文档能替代的,该问的时候还是要问。