先说结论
邮箱插件最危险的地方，是人很容易把“点了允许”误当成“插件以后就永远能进来”。Mail Plugin 的源码恰恰在努力拆开这两件事：用户先确认一次，插件再用短期 code 换取长期 token。
第一层：为什么授权页必须要求 internal user
auth() 一上来就拒绝非内部用户。这条边界很关键，因为邮箱插件接入后拿到的不只是一个页面访问权，而是可以代表用户调用 Odoo 接口的长期凭据。官方显然不希望把这种能力开放给 portal 或外部账号。
第二层：auth code 为什么要短命
_generate_auth_code() 生成的消息里带 scope、name、timestamp 和 uid，并经过 HMAC 签名；_get_auth_code_data() 又把有效期限制在 3 分钟。这样做的逻辑很像 OAuth 临时授权码：浏览器跳转过程中可用，但不适合长期存活。
第三层：为什么还要先跳回 redirect 再换 token
auth_confirm() 把 auth_code 带回插件指定的 redirect，之后插件再调用 auth_access_token() 来换 API key。这个双跳结构的意义是：浏览器页面负责让人做授权决定，后端接口负责签发长期访问凭据。它们不是一个环节。
第四层：access token 为什么其实是 API key
auth_access_token() 最终调用的是 res.users.apikeys._generate()。也就是说，插件拿到的不是某种一次性会话票据，而是受 scope 约束、带过期时间的 API key。看懂这点，你就知道 Mail Plugin 的接入本质上属于“受控 API 授权”，而不是单纯网页登录。
第五层：这条链最适合防什么问题
它主要防三类问题：中途篡改授权码、过期 code 被重复利用、以及未经过人工确认的静默接入。对邮箱插件这类半桌面、半 Web 的集成来说，这三件事都很常见。
最容易误解的三个点
- 误区一：插件能打开网页就说明已经安全接入。真正关键的是后续 API 凭据如何签发。
- 误区二：临时 code 越久越方便。安全上恰恰相反，越短越稳。
- 误区三：Mail Plugin 是“网页登录的另一个壳”。实际上它更接近受控 API 授权流程。
实战上怎么用更稳
- 排查插件接入失败时，先分清是授权页阶段、redirect 阶段，还是 token 交换阶段。
- 如果你扩展类似插件，不要让浏览器页面直接发长期 token。
- 遇到“明明授权过还失效”，优先检查 API key 过期而不是先查前端。
最后总结
Mail Plugin 的重点，不是把邮箱和 Odoo“连上”，而是把一次人工授权安全地转译成一把受限、可过期、可审计的访问钥匙。
DISCUSSION
评论区