imtoken钱包授权接口对接指南：从签名到异常排查

在做 DApp 对接 imtoken 钱包的时候, 签名还有授权, 这两个环节是最容易让人卡住的。

imtoken 钱包授权的接口, 从本质上来说, 是一套结合了 EIP-191 与 EIP-712 的签名流程, 再加上通过钱包弹窗来进行确认的过程, 但是, 在实际的开发工作当中, 会遇到的坑是非常不少的, 并且provider初始化方式如何去做, 直接就会决定后续的签名功能能不能够顺利地运行通畅。

imtoken授权接口怎么调

在调用之前，需要先去确认钱包软件已经安装好了, 并且处于解锁状态。之后, 可以通过window.ethereum.request({method:'eth_requestAccounts'})这个步骤来获取相关的账户信息。

imtoken是不支持直接去注入web3对象的, 这必须得走EIP-1193这个扩展通道。但是呢, 在很多DApp的操作流程里, 它们是跳过了这一步前置检查的, 这就导致了后续的签名操作会直接返回用户拒绝或者是超时。

关于签名, 它主要是分成了两种场景来的, 就比如说个人签名的话, 那是走personal_sign这一条路, 而如果是合约交互的话, 那就得走eth_signTypedData这一条路了。

imtoken这个软件对于EIP-712typeddata的支持程度比个人的签名操作要更完善一些。但是里面有一个字段是ChainID, 这个值必须严格地进行匹配才可以。如果匹配不上, 弹窗界面就会直接显示出“未知链”这几个字给到用户, 然后让用户自己去选择取消相关的操作步骤。

imtoken授权接口签名异常

在大家遇到的绝大多数报错情况里面, 最经常被提及到的错误信息就是“method not found”, 造成这个结果的一般原因, 是有人把window.ethereum给当成了旧版本的web3库那样去直接调用处理了, 要知道imtoken所暴露出来的是符合EIP-1193标准的接口, 它里面的参数格式以及回调机制这些内容, 和web3完全是两码事不一样的存在, 如果把这些东西混在一块去用那肯定是要出问题的会挂掉的。

存在着另外一种可能的情形, 那就是在对签名进行返回的时候, 在hex格式数据的前面, 额外地增加了重复的“0x”这个前缀标识, 这种意外的情况直接导致了后端系统在调用verify方法进行验证签名的过程中发生失败。

imtoken的某些版本针对eth_signTypedData方法的返回值, 存在前缀处理上的差异情况, 在进行接口联调工作的时候, 我们建议你要把原始的返回值直接打印出来, 然后跟预期的那个值进行逐字节的比对操作, 千万不要仅仅只去看length这个字段的长度数值。

在把相关的事情对接完毕之后, 需要在测试网络里面把整个流程走一遍, 等到主网要上线之前的时候, 要把nonce字段以及gas字段再进行一次验证, 千万不要等到用户进行投诉的时候才猛然发现原来的签名链ID是写死的状态。