我今天把养基宝 `browser-plug-api.yangjibao.com` 这一套扫码登录链路重新顺着代码和现有实现查了一遍。把 `/qr_code` 单独拿出来看，很容易产生一个误解，仿佛服务端返回的是一张特殊图片，图片内部可能保存着养基宝账号、基金账户、手机号，甚至直接保存着后续访问接口所需要的 `Token`。从目前能够查到的代码和实际项目实现看，并不是这样的。

`/qr_code` 更适合理解成一次扫码登录会话的创建接口。调用它以后，养基宝服务端创建一个临时登录上下文，返回两个非常重要的数据，`id` 和 `url`。公开实现中的调用逻辑就是从返回结果里分别取出 `id` 和 `url`，代码随后把 `url` 交给二维码生成库，真正画成我们看到的黑白二维码。与此同时，`id` 并没有被拿去画二维码，而是保留起来，供程序不断访问 `/qr_code_state/{id}` 检查扫码登录进度。([GitHub][1])

所以，回答这个问题最核心的一句话可以写成

**养基宝 `/qr_code` 所显示出来的二维码，直接编码进去的是接口返回的 `url` 字符串，而不是最终登录 `Token`，也不是我们的基金持仓数据。**

这一点其实可以从现有 Python 实现直接确认。代码取得 `qr_url` 后，做的是下面这种处理

```python
qr_id = qr_data.get(`id`)
qr_url = qr_data.get(`url`)

qr = qrcode.QRCode()
qr.add_data(qr_url)
qr.make(fit=True)
```

这里真正送进 `qrcode` 库的只有 `qr_url`。`qrcode` 库并不知道什么叫养基宝账号，也不知道什么叫基金持仓，更不知道后面会不会产生 `Token`。它做的事情非常机械，把一段字符串按照 QR Code 编码规则转换成二维黑白模块。公开实现甚至提供了降级方案，没有 `qrcode` 库时，直接把同一个 `qr_url` 打印出来，或者把它交给第三方二维码生成服务。这进一步说明二维码图片只是 `url` 的视觉编码形式，真正有业务意义的是二维码背后的那段字符串。([GitHub][1])

普通 QR Code 本来就是一种数据载体。里面可以编码纯文本、网址、电话号码、Wi-Fi 配置或者其他字节数据。手机相机看到的是一堆黑白方格，扫码程序经过定位、纠错和解码之后，恢复出来的其实仍然是一段数据。养基宝这里选择的是 `url`。因此，把二维码想成一个漂亮的信封并不准确，它更像一张机器可读的小纸条，纸条上写着某个临时登录入口。QR Code 自身并没有神奇的身份认证能力，身份认证是养基宝 App 和养基宝服务器围绕这段 `url` 完成的。([Wikipedia][2])

这里还有一个很重要的细节，`url` 并不等同于最终的 `Token`。

从目前能够查到的养基宝扫码登录实现看，调用 `/qr_code` 时并不已经拥有用户登录 `Token`。相反，整个设计正是为了通过扫码流程获得 `Token`。服务端返回 `{id, url}` 后，电脑这一侧显示二维码，同时保存 `id`。程序开始周期性访问 `/qr_code_state/{id}`。手机里的养基宝相关客户端扫描二维码并完成授权以后，服务器更新这个临时登录会话的状态。等登录状态进入成功阶段，查询状态的接口才会返回 `token`，电脑端程序再把这个 `token` 保存下来，用它访问账户和持仓之类的私有接口。([GitHub][3])

也就是说，可以把整个过程画成这样

```text
电脑程序
    |
    | GET /qr_code
    v
养基宝服务器
    |
    | 返回 id + url
    v
电脑把 url 编码成 QR Code
    |
    |              id 保存在电脑程序里
    |                      |
    v                      v
手机扫描 QR Code      /qr_code_state/{id}
    |                      ^
    |                      |
    v                      |
养基宝服务器 -----------+
    |
    | 手机身份得到确认
    |
    v
登录会话状态改变
    |
    v
/qr_code_state/{id}
    |
    | 返回成功状态 + token
    v
电脑保存 token
    |
    v
访问 /user_account
访问 /fund_hold
访问 /account_collect
……
```

这张流程图里有一个很容易被忽略的分界线。

二维码解决的是手机和电脑之间如何围绕同一次临时登录会话建立联系。

`Token` 解决的是扫码成功之后，电脑以后以什么身份访问养基宝的私有数据接口。

两者属于前后两个阶段。

现有开源实现里，在成功得到 `Token` 以后，程序才开始用带有 `Authorization` 的请求访问账户、持仓和收益数据。Firefox 上由 `yangjibao` 发布的养基宝扩展目前也明确申请了访问 `browser-plug-api.yangjibao.com` 的权限，说明这一域名确实承担着浏览器插件侧的数据交互。([Firefox Add-ons][4])

回到二维码里究竟有什么这件事，可以进一步把数据分成三层。

第一层是我们肉眼看到的二维码图片。

它只是视觉表达，PNG、Canvas、终端字符二维码，甚至纸上打印出来，业务意义都没有改变。只要编码的原始字符串一样，扫码得到的内容就一样。所以二维码的黑白格本身不是身份凭据，它们只是某个字符串的机器可读表现。

第二层是二维码解码出来的 `url`。

这是目前可以从代码直接确认的内容。现有 Python 实现明确调用 `qr.add_data(qr_url)`，另一个较完整的养基宝集成项目也明确记录 `/qr_code` 返回 `{id, url}`，前端利用 `url` 生成二维码。这里可以下确定结论，QR Code 的 payload 就是这个 `url`。([GitHub][1])

第三层才是 `url` 在养基宝服务端所代表的登录上下文。

这一层需要稍微谨慎一些。目前公开可检索资料能够确认它参与扫码登录，并且和 `/qr_code_state/{id}` 所代表的登录会话存在对应关系，但我没有找到养基宝官方公开文档完整公布 `url` 的字段结构，也没有找到官方文档逐字符说明其中每个参数的语义。因此，不能负责任地声称这个 `url` 一定长成某个固定格式，也不应该虚构诸如 `userId=xxx`、`token=xxx` 这样的参数。

从协议行为可以做出一个相当可靠的工程判断，那个 `url` 应当携带或者指向某种一次性登录挑战标识，使手机扫码后能够告诉服务端，当前手机上的养基宝身份正在处理哪一次电脑端登录请求。这个标识有可能就是和 `id` 直接关联的值，也可能是另外一个随机 nonce、ticket、session key 或者服务端映射后的临时凭据。由于没有官方字段说明，具体内部表示形式应该保留为未知，而不是把推断写成事实。现有项目文档也采用了比较谨慎的表述，把 `url` 描述成二维码内容以及养基宝 App 使用的扫码链接。([github.com][3])

这里可以用我们今天正在研究的这个 Python 程序作为真实工程案例。

程序执行

```bash
python yjb_tool.py --login
```

进入 `qrcode_login()`。

它创建一个没有现成用户 `Token` 的 `YJBClient`，调用

```python
client.get(`/qr_code`)
```

取得 `id` 和 `url`。接着程序把 `url` 生成二维码显示出来。与此同时，它并没有说扫码完成，也没有立刻访问 `/fund_hold`，而是进入等待循环，每隔几秒请求一次

```text
/qr_code_state/{qr_id}
```

只有状态接口最终给出了 `token`，程序才执行保存操作，把 `token` 放进本地 `~/.yjb_token.json`。公开项目的 README 也明确说明，首次使用需要扫码登录，成功后的 `Token` 会保存在本地，过期以后需要重新扫码。([GitHub][1])

从这个顺序就能推出一个非常重要的安全结论。

**二维码本身大概率不是已经登录完成后的长期访问凭据。**

原因很直接，如果二维码里已经放着最终 `Token`，程序根本没有必要继续调用 `/qr_code_state/{id}` 等待服务器返回 `Token`。扫描二维码之前，最终用户身份还没有与电脑端这次登录正式绑定。二维码承担的是登录握手入口，成功身份凭据是在扫码流程完成之后才产生或者才暴露给电脑端的。

这种设计和很多桌面端扫码登录系统的思路很接近。

电脑端无法直接读取手机 App 中已经存在的登录 Session，但手机已经知道当前登录的是哪个账号。于是服务器先给电脑一张临时取号单。电脑把取号单画成二维码。手机扫描之后，相当于告诉服务器，当前手机上的已登录身份准备为这张取号单办理授权。服务器把两侧关联起来，电脑继续拿着原来的号码查询状态。认证完成以后，服务器才把电脑端所需要的新会话凭据交给电脑。

这里的取号单对应 `url` 和它背后的临时 challenge。

电脑保存的号码对应 `id`。

最后拿到的门禁卡对应 `Token`。

这个类比有一个很有用的地方，它能够解释为什么不能把 `id`、`url` 和 `Token` 混成同一个东西。

`id` 主要是电脑端查询这次扫码会话状态的索引。

`url` 是手机扫描二维码后所消费的数据。

`Token` 是成功完成身份授权后，电脑访问私有 API 时使用的认证凭据。

三个东西看起来都像随机字符串，但生命周期、持有者以及安全价值完全不同。

另外，二维码里面通常也没有必要直接塞入基金代码、基金份额、成本金额、账户名称之类的数据。养基宝官网对自己的定位本身就是基金数据展示和管理工具，用户持仓属于登录后的个人数据范围。扫码认证完成以后，客户端才通过诸如账户、持仓和收益接口读取这些数据。养基宝官方关于产品的介绍也说明它支持把多个平台的基金持仓集中管理和展示，而不是让二维码直接承载这些持仓信息。([Yangjibao][5])

因此，如果现在把这个二维码用普通 QR Code 解码器扫一下，理论上看到的应该是一段 URL 或 URI 样式的数据，而不是类似下面这样的基金 JSON

```text
{
  account: ...,
  funds: ...,
  money: ...,
  token: ...
}
```

现有代码已经给出了非常强的证据，因为程序本身甚至会直接输出 `qr_url`。在缺少二维码库的时候，它不需要另外请求二维码图片，而是告诉程序使用者直接处理这个 `qr_url`。这证明二维码和 `qr_url` 是同一份信息的两种表示。([GitHub][1])

还有一个常见疑问，既然二维码只是一个 URL，那么把这个 URL 复制给另一台手机，会不会也能扫描。

从 QR Code 编码层面当然可以，因为图像只是 URL 的编码。把同一个字符串再次生成二维码，扫码结果不会因为二维码图片换了而改变。不过登录系统通常给这种 URL 对应的临时会话设置有效期，而且成功使用后可能失效或者状态发生改变。现有养基宝集成实现也明确提到二维码存在时效，超时以后需要重新创建登录流程。([github.com][3])

这也是为什么二维码登录不能被理解成静态账号名片。

静态二维码更像个人主页地址，今天扫描和一个月后扫描结果可能完全相同。

登录二维码更像某次握手的临时邀请函，它和服务器中的临时状态配套工作。二维码图片可能仍然保存在截图里，但对应服务器会话已经过期以后，那张截图基本就失去了登录价值。

从安全角度看，这一点也相当关键。

QR Code 没有加密魔法。只要第三方能够看到二维码，就原则上能够解码出里面的 `url`。真正防止别人借二维码直接长期控制账号的，是后端登录协议，包括临时 challenge、过期时间、扫码状态、手机端身份认证以及最终 `Token` 的签发和管理，而不是黑白方格本身。养基宝隐私政策也强调账号和个人信息需要安全保护，而从工程实现看，最终需要重点保护的是扫码成功后获得的认证 `Token`。([Yangjibao][6])

所以，如果在调试程序时看到下面这种返回

```text
data
 ├─ id
 └─ url
```

理解方式应该是

```text
id
电脑保存
用于跟踪这一次 QR 登录会话

url
编码进 QR Code
手机扫码时读取

Token
此时通常还不存在于电脑端
完成扫码认证以后
通过状态查询流程返回
```

这里还有一个特别值得留意的问题。

`/qr_code` 和 `/qr_code_state/{id}` 构成了一套 challenge-response 风格的认证协调过程，但并不是传统意义上的密码 challenge-response 算法。电脑没有拿密码对 challenge 做签名。更准确地说，养基宝服务器创建临时扫码登录 session，手机客户端利用自己已有的认证身份处理这个 session，电脑则通过轮询观察 session 状态，最终获得新的 API 身份凭据。

这也解释了为什么 `/qr_code` 自身可以在没有用户 `Token` 的状态下调用。

如果调用 `/qr_code` 本身就必须带有效用户 `Token`，扫码登录会陷入循环，必须先登录才能获得登录二维码。现有实现创建 `YJBClient` 时允许 `token` 为空，再调用 `/qr_code` 创建二维码登录流程，而真正读取持仓的 API 才依赖扫码后取得的 `Token`。([GitHub][1])

值得把另一个细节也讲清楚。现有第三方实现展示了一套基于 `Request-Time`、`Request-Sign` 和 `Authorization` 的请求机制。即使二维码创建阶段 `Authorization` 可以为空，请求本身仍可能带时间戳和签名。扫码登录解决的是用户身份，API 请求签名解决的是客户端请求格式和完整性验证，这两个安全层不要混为一谈。扫码得到的是用户会话，MD5 请求签名属于 API 协议的一部分。([github.com][3])

目前网络上还出现了多个利用同一套接口实现扫码登录的项目。一个较新的 Fund Helper 项目把流程实现到了 VS Code 和 Cursor 扩展里，Webview 发起 `startLogin`，Extension Host 调 `getQrcode()`，界面绘制二维码并每隔约两秒发送状态查询，当状态成功并返回 `token` 后才保存 Session 并读取持仓。这个独立实现与前面的 Python 工具在核心时序上是一致的，所以关于 `二维码 -> 状态轮询 -> Token` 这一结构，证据已经相当充分。([Visual Studio Marketplace][7])

至于二维码 `url` 的每一个字符究竟是什么，当前公开资料还不够支持逐字段定论。这一点反而需要刻意保持严谨。我尝试直接访问当前 `/qr_code` 接口以取得一份实时响应，但公开 Web 抓取无法成功读取这个动态接口，因此目前不能拿一份刚生成的 `url` 来逐字符解析。现有代码和多个独立实现足以确认二维码编码对象就是返回的 `url`，也足以确认最终 `Token` 来自后续扫码状态流程，但还不足以断言 `url` 内部到底使用 `id`、随机 ticket、nonce、签名参数还是另一层服务端映射。

因此，现阶段最准确的认识可以浓缩成这样一条链

```text
GET /qr_code

        ↓

养基宝服务端创建一次临时登录会话

        ↓

返回 id + url

        ↓

程序把 url 编码成 QR Code

        ↓

手机端扫描并识别 url

        ↓

养基宝服务端把手机当前登录身份
与这一次临时登录会话关联

        ↓

电脑不断请求 /qr_code_state/{id}

        ↓

登录授权完成

        ↓

状态接口返回 Token

        ↓

电脑持有 Token

        ↓

后续请求 user_account
fund_hold
account_collect
以及其他私有数据接口
```

所以，当 `/qr_code` 出来以后屏幕上出现一个二维码，我们看到的并不是基金数据的二维码，也不是把手机里的养基宝账号复制到电脑上的二维码。它更接近一张临时的跨设备登录握手凭证。QR Code 内直接保存的是服务端给出的 `url`，这个 `url` 负责让手机端进入并识别某一次临时登录流程。电脑端同时握着对应的 `id` 不断询问服务器扫码进展。真正具有长期 API 访问价值的 `Token`，是在手机完成扫码身份确认以后，才通过后面的状态查询链路交给电脑端。

从协议设计角度看，`url` 是入口，`id` 是追踪号，`Token` 才是扫码成功之后得到的通行证。把这三个角色区分开，养基宝 `/qr_code` 这一套登录机制基本就看透了。

[1]: https://github.com/Ye-Yu-Mo/yjb-api/blob/main/yjb_tool.py?utm_source=chatgpt.com "yjb-api/yjb_tool.py at main"
[2]: https://en.wikipedia.org/wiki/QR_code?utm_source=chatgpt.com "QR code"
[3]: https://github.com/liukai-code/xiaomo-investment-agent/blob/main/docs/Highlights/12-YangJiBaoIntegration.md "xiaomo-investment-agent/docs/Highlights/12-YangJiBaoIntegration.md at main · liukai-code/xiaomo-investment-agent · GitHub"
[4]: https://addons.mozilla.org/en-US/firefox/addon/yjb_fund/ "养基宝 - 实时查看基金收益 – Get this Extension for 🦊 Firefox (en-US)"
[5]: https://yangjibao.com/about.html?utm_source=chatgpt.com "关于我们- 养基宝官网"
[6]: https://page.yangjibao.com/policy.html?utm_source=chatgpt.com "养基宝隐私协议"
[7]: https://marketplace.visualstudio.com/items?itemName=fund-helper-org.fund-helper-vscode&utm_source=chatgpt.com "Fund Helper · VS Code / Cursor 扩展"


我今天把养基宝 browser-plug-api.yangjibao.com 这一套扫码登录链路重新顺着代码和现有实现查了一遍。把 /qr_code 单独拿出来看，很容易产生一个误解，仿佛服务端返回的是一张特殊图片，图片内部可能保存着养基宝账号、基金账户、手机号，甚至直接保存着后续访问接口所需要的 Token。从目前能够查到的代码和实际项目实现看，并不是这样的。

养基宝 /qr_code 里的二维码到底装了什么，真正关键的不是图片，而是一张临时登录凭证的入口

紫薇堂堂主

网络与通信

安全

开发工具

养基宝扫码登录中，二维码编码的是接口返回的URL字符串，而非Token或持仓数据。该URL作为临时登录会话入口，手机扫码后服务端将身份与会话关联，电脑通过轮询/qr_code_state/{id}获取最终Token。URL、id和Token分别承担入口、追踪和认证凭据三个不同角色。

数据接口

代码解释

服务器

Python

GitHub

JSON

热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

养基宝 /qr_code 里的二维码到底装了什么，真正关键的不是图片，而是一张临时登录凭证的入口-腾讯云开发者社区-腾讯云

养基宝 /qr_code 里的二维码到底装了什么，真正关键的不是图片，而是一张临时登录凭证的入口

养基宝 /qr_code 里的二维码到底装了什么，真正关键的不是图片，而是一张临时登录凭证的入口

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐