T13 · Wallet Connection

一个现实问题

产品说：「加个钱包登录吧，跟微信登录差不多。」

你点开任意一个 DApp，右上角「Connect Wallet」，弹窗，确认，头像出来了。看上去确实差不多。

但把这个流程拆开看，你会发现它至少由三件完全不同的事情拼成：

• 浏览器插件把一个地址交给了页面——这件事没有经过任何验证，页面只是「被告知」了一个地址。
• 页面弹出一个签名请求，用户点了确认——这一步证明了什么？证明给谁看？
• 有些站点在登录之后立刻又弹一个窗，标题是「授权」，用户以为还是登录流程的一部分，也点了确认——这一下，可能把钱包里的全部某种代币交了出去。

三件事长得很像：都是弹窗，都是点确认。但它们的后果完全不同。第一件事什么都没发生，第二件事最坏情况是你的账号被别人用，第三件事最坏情况是你的钱没了。

用户分不清，是因为很多产品自己也没分清。 这一章要做的，就是把这三件事彻底拆开。

思想实验

把一把钥匙想成三样东西。

你入职一家公司，前台给了你一枚工牌。这枚工牌同时是：

1. 一张门禁卡——刷一下，闸机开了。它只证明「你是员工」。
2. 一枚签名章——盖在文件上，证明「这份文件我看过、我认可」。
3. 一支能签空白支票的笔——签下去，财务就得付钱，而且签一次可以被反复兑付，直到你去把它挂失。

现实世界里这三样东西不会做成一个。门禁卡丢了补办一张，签名章丢了去公证处挂失，空白支票根本不会有人发给你。

Crypto 钱包的私钥把这三件事合并成了一个。同一枚私钥，既能刷门禁，也能盖章，也能签出那张可以被反复兑付的支票。区别不在于用了哪把钥匙，而在于你签的那张纸上写了什么。

而那张「可以被反复兑付的支票」在链上是有状态的：签出去以后会一直有效，直到你主动发一笔交易把它撤掉。关网页、清缓存、换电脑，它都还在。这是 Web2 的登录里完全不存在的一类东西。

于是问题变成：用户能不能看懂他正在签的那张纸？

你来决定

你要给自己的 DApp 做登录。四种做法，你选哪种？

观察结果

四个选项真正暴露的，是这样一件事：「连接」「认证」「授权」是三个不同的动作，只是在界面上都表现为一个弹窗。

两格值得单独拎出来。「没人验证」是最容易被跳过的一格：连接钱包拿到的地址谁都能伪造，它能用来展示，不能用来鉴权。「没有期限」是唯一一个「关掉网页也还在」的格子：所以授权必须有一个撤销入口，而且这个入口是你的产品的一部分，不是让用户自己去别处找。

还有一条这张表没画出来的：「不上链」不等于「没风险」。 一条链下签名本身就可以是一张授权令牌——后面「真实案例」里会看到，最凶的几起钓鱼全都不需要用户发交易。

建立模型

把登录拆成五段，每一段职责单一：

被签的内容决定一切

签名请求分三类，风险差了几个数量级：

第三类叫盲签：用户看到一串没有意义的字符，确认之后可能发生任何事。如果你的产品要求用户盲签，你的产品设计有问题。

第二类更值得警惕，因为它看起来是安全的。一个字段叫 spender、值是一个地址，另一个字段叫 value、值是一个 78 位的数字——每个字段用户都「看见」了，但没有一个用户能从中读出「我把全部余额的动用权给了一个陌生地址，有效期一年」。

如实展示的标准不是「把原始数据显示出来」，而是「用户看完能说出后果」。 这两件事差得很远。

登录消息应该长什么样

用一段纯文本来表达，字段的语义比格式重要：

example.com 希望你用这个地址登录：

0x<你的地址>

点击签名即表示你同意登录 example.com。
这次签名不会发起交易，也不会授权任何资金操作。

Chain ID: <链 ID>
Nonce: <后端生成的一次性随机数>
Issued At: <签发时间>
Expiration Time: <过期时间>

每个字段各自堵死一类攻击：域名堵死跨站重放，地址堵死拿别人的签名冒充，Chain ID 堵死跨链重放，Nonce 堵死同站重放（用完必须立刻在后端作废），过期时间限制签名被盗后的可用窗口。

那句「不会发起交易，也不会授权任何资金操作」不是客套话，它是你对用户的承诺。用户每见一次这句话并且事后证实为真，他对弹窗的信任就积累一分；你在登录里偷偷塞一次授权，透支的是整个行业的信任。

会话的生命周期

签名验过之后，发一个普通会话凭证就行，和 Web2 完全一样。但有三个 Crypto 特有的失效条件：

type WalletSession = {
  address: string;      // 认证通过的地址
  chainId: number;      // 认证时所在的链
  issuedAt: number;
  expiresAt: number;
};

// 必须立刻销毁会话的三种情况：
// 1. 钱包切换了账户，当前地址不再等于 session.address
// 2. 钱包切换了链，业务要求单链时 chainId 不匹配
// 3. 钱包断开连接

第一条最容易漏。用户在钱包里切到另一个账户，页面上的会话还是旧地址——于是他用 B 账户的界面，操作着 A 账户的数据。处理方式很简单：监听账户变更事件，一旦地址变了就立刻销毁会话并要求重新认证，而不是「静默切换」。

授权要按需、按额、可撤销

授权是一笔上链交易，设计它的时候只有三个问题：

1. 什么时候弹？ 在用户第一次真的要用到那个功能的时候，不是在登录时。
2. 额度给多少？ 给这次操作需要的量，不是无限。无限额度省下的那一次点击，换来的是永久的敞口。
3. 怎么撤？ 你的产品里必须有一个页面，能列出用户在你这里授过的权，并且一键撤销。

第 3 条是这一章 Lab 的一半。很多团队觉得「用户可以去别的工具撤销」，但你的产品制造的风险，应该由你的产品提供出口。

它叫什么

动手

AI Lab

第一步：
列出 Crypto 钱包签名钓鱼的常见形态。对每一种说明：
- 攻击者让用户签的是什么类型的数据
- 用户在钱包弹窗里实际会看到什么
- 签完之后攻击者能做什么、需不需要用户再做别的操作
- 从用户的视角，有没有任何可识别的信号

第二步：
这是我的登录与授权界面的文案和弹窗内容（贴上你的实际内容）。
按上面每一种形态逐条检查：我的界面在这个点上，是如实展示了，
还是有可能让用户误判？给出具体的改法，不要给笼统建议。

真实案例

改一个变量

带走的问题

本章自测