Rhinestone permissions真是白名单吗？核fallback、旧permission ID与签名权限
链小知 · 进阶 · 核验 · 依官方文档整理
按自定义EVM Session材料检查授权边界，避免修改新配置却仍留下旧宽权限。
开始前准备
- 准备自己已有的脱敏配置、日志或状态回执，保留产品版本、对象、字段和日期；缺值不补成成功或零。
1. 固定SDK表面与启用状态
本篇按@rhinestone/sdk 3.0.0自定义EVM Session说明，记录账户、chain、session signer、permission ID和validator启用材料；createSession定义不等已上链启用，可按既有isSessionEnabled结果核。managed Solana的Swig allButManageAuthority不是本套token预算/allowlist/expiry，不能移植相同保障。
检查结果：SDK、EVM链、signer、permission ID与启用结果分别有证据或未知。
2. permissions与intent fallback分开
permissions按ABI绑定地址/函数，参数限制按ABI名称配置。仅列permissions并非严格allowlist：默认仍有wildcard intent-execution fallback，未匹配调用可经Orchestrator的intent target allowlist作为intent执行。检查restrictToActions=true才知道是否移除这一路；函数参数未设限制时，也不能因函数在列表里就认为金额/收件人固定。
检查结果：显式调用权限、参数限制与fallback各有设置依据。
3. 限制调用还要核非空与碰撞规则
restricted Session至少含一个permission或action；actions必须同时有target、selector，不能指fallback sentinel，也不能与permissions在同一target/selector碰撞，否则共用同一on-chain action ID。restrictToActions不可与crossChainPermits或claimPolicies并用，因为其支出/时间守卫依赖fallback。缺raw actions或claim配置时，限制有效性仍未知。
检查结果：非空、target/selector、sentinel、同键碰撞和互斥配置已逐项核。
4. strict salt不替撤销旧宽授权
saltMode默认none使用zero salt，同signer即使actions变更也可复用permission ID，再enable会增加policy而非替换。strict使不同restricted定义有不同ID，但signer仍控制之前每个ID；收窄时须核旧宽Session已撤。disableSession仅撤单Session，disable卸整个validator及其Sessions；prepared或签过撤销意图不等实际撤销成功，缺执行结果保留旧授权未知。
检查结果：新定义、旧ID与撤销范围/结果分别记录；未把换salt当链上撤权。
5. ERC1271签名权限单独验收
普通Session省略signing默认为unrestricted且无有效期；restricted/swap-scoped默认disabled，可显式再启用。scoped按EIP712 domain与canonical primary-type schema匹配，不限制token/amount/spender/deadline等消息值。unrestricted/scoped时间窗为Date配置，不能套另一客户端的Unix参数。当前可配置/enable scoped，但直接scoped signTypedData仍暂不可用直到安全ERC7739发射恢复；失败快返不等策略已绕过或签出成功。
检查结果：执行范围、签名模式、domain/schema、值限制与当前不可用分支均分开。
怎样确认完成
- 形成输入、官方判定方法、已知结果和未知分支的对照；方法已核，实际运行与本人权限未验证。
常见错误与边界
- 同signer可能仍持多个旧permission ID；单个新Session变窄不等总体权限变窄。
- 具体params只能限制已编码字段，不从ABI显示名称或产品宣传推断资金预算和x402支付限制。