一次真实的排查：AK/SK 签名通了却 403 not login，问题出在登录态而不是签名

一、现象

用 AK/SK 签名调一个业务接口，签名算法反复核对过、时间戳格式正确、SignedHeaders 也一致，服务端却稳定返回 403，body 只有一个短语：not login。

第一反应通常是"签名错了"。但如果真是签名错，返回的应该是 APIGW.0101（接口不存在）或 401 一类的鉴权失败码，而不是一句"未登录"。"not login" 说的是身份状态，不是签名有效性——这两个是不同层的事。

二、为什么 AK/SK 也会"未登录"

云平台的接口通常分两类：

• 开放 API（如 ECS/VPC/EIP/BSS 的管理面）：设计目标就是给程序调，认 AK/SK 签名，不依赖浏览器会话；
• 站点业务接口（如开发者社区的积分、任务、消息）：设计目标是给网页用的，认的是浏览器登录态——cookie 加一个 CSRF 令牌。

第二类接口根本不校验 AK/SK。对它来说，你没有 cookie，就是"未登录"，签名再正确也没用。

三、怎么快速区分是哪一类

不要改签名去试错，先用返回值判断：

• 返回 APIGW.0101 The API does not exist → 签名是通的，只是路径写错了，去核对路径；
• 返回 401 / SignatureDoesNotMatch → 签名真的有问题；
• 返回 not login / no request_csrf found → 接口属于站点业务层，AK/SK 这条路走不通，应该换思路。

这个判据能省掉大量无效尝试：把"改签名重试"变成"先看服务端在抱怨哪一层"。

四、那这类数据该怎么拿

结论分两种，取决于有没有替代路径：

1. 有开放 API counterparts：优先用开放 API。例如账号侧的代金券与账户余额，就能用 AK/SK 走 BSS 全局接口查到，包括余额与到期时间。
2. 只有站点接口：例如社区的积分与任务状态，就只能用浏览器会话读。此时不要试图逆 CSRF 的生成方式——那是在跟一个会随时变更的前端实现较劲，收益低、维护成本高。读渲染后的页面往往就够用，而且天然跟随站点改版。

五、一条可以推广的排查原则

遇到鉴权类失败，先问"服务端拒绝的是哪一层"，再决定改什么：

签名层  → 路径/参数/编码/时间戳
身份层  → cookie / token / 登录态
权限层  → 策略是否允许该操作

三层都可能返回"看起了像鉴权失败"的错误，但修法完全不同。把力气花在正确的层上，比反复重试同一个层有效得多。

六、小结

1. not login 是身份层的问题，不是签名层；
2. 开放 API 认 AK/SK，站点业务接口认浏览器 cookie + CSRF，两类不要混用；
3. 用返回码先分层，再决定修哪里，能避免大量无效重试；
4. 站点侧数据优先读渲染后的页面，而不是逆前端的令牌机制。