 lovife
|
d8463a051f
|
verify(storage): 七牛云接通并验证通过 —— 对象存储这块完成
根因就是那个"多出来的一个字符"：secret-key 原来是 **41** 字符，
而七牛的 AK/SK 都是 40 字符的 URL 安全 base64。用户重新复制后（SK 40 字符）一切正常。
排查方式值得记：没有凭一次失败下结论，而是做了三次互相独立的验证 ——
① 我手写的管理 API 签名（可能是我的 bug，不能作数）
② 应用启动自检里的**七牛官方 SDK** 的 uploadToken
③ 一个**能把原因分开**的调用：BucketManager.stat(bucket, 一个一定不存在的键)
612 = 鉴权通过（只是文件不存在）/ 401 = 密钥无效 / 631 = bucket 名不对
三次一致指向"密钥无效"，所以给用户的结论是确定的，而不是"可能是配置问题"。
验证证据：
启动自检通过：写入 → 存在 → 读回 → 删除 全部正常（provider=qiniu）
材料存储：七牛云（bucket=tools-matrix domain=https://file.tools.coding.design）
e2e-m1-storage.py 16/16：
· 签名链接形如 .../xiaotutongxue/std/1/17/%E5%BC%A0%E5%90%8C%E5%AD%A6-…?e=…&token=…
· **中文对象键逐段编码正确**（就是设计时专门防的那个坑）
· 签名链接下载回来是真 JPEG、非空
· **不带签名的裸地址被拒（401/403）→ 空间确实私有，签名在起作用**
· 对象键带 xiaotutongxue/ 前缀
· **原始件字节与上传的一模一样**
全量回归 370 条断言、0 失败（此时 provider=qiniu，文件真的进七牛）
顺带修掉一条"写死了存储位置"的 E2E 断言：e2e-m3-file.py 原来断言
「原始文件真的存在磁盘上」，切到七牛后整片变红，而那看起来像代码坏了。
改成通过产品接口把文件取回来比字节（GET /mp/files/{id}/url → 下载）：
对两种 provider 都成立，而且比原来更强（顺带验了签名链接、私有访问、内容完整性）。
教训：**在"可替换的实现"上写断言，等于把测试绑死在一种实现上。**
状态：backend/application-local.yml 已是 provider: qiniu（密钥 gitignore、不进 jar）；
生产用 XT_STORAGE_PROVIDER=qiniu + QINIU_ACCESS_KEY/QINIU_SECRET_KEY。
|
2026-09-29 14:52:51 +08:00 |
|