编写数据库触发器时，如何不存储Facebook Access Token获取触发用户令牌？

兄弟，先给你拍板结论：数据库触发器完全没办法直接获取到Facebook的access token，而且从安全层面看，你不想把token存进数据库的思路特别正确，这玩意儿真不能碰数据库。

为啥不行？以及有啥替代方案，咱给你掰扯清楚：

核心原因：上下文完全隔离 #

不管你用的是Android本地的Room/SQLite，还是后端的MySQL/PostgreSQL，数据库触发器都是运行在数据库服务进程里的，它只能访问数据库内部的数据、当前数据库连接的上下文（比如数据库层面的用户身份），根本碰不到Android客户端内存里、或者Keystore中存储的Facebook access token。

Facebook的access token是客户端侧的敏感临时凭证，本来就不该流出客户端内存/安全存储，存数据库等于把风险放大N倍——哪怕加密都有泄露隐患，你这个顾虑太到位了。

可行的替代思路 #

既然触发器拿不到token，那得换个逻辑路径实现你的需求：

• 把需要token的逻辑移出触发器
  如果你的触发器原本想用token做什么（比如调用Facebook API、验证用户权限），把这部分逻辑移到客户端或者后端服务：

  • 要是用的是本地数据库（比如Room）：客户端在执行数据库操作前/后，直接用内存里持有的token完成对应的逻辑就行，根本不需要触发器插手。
  • 要是用的是后端数据库：后端服务接收客户端请求时，让客户端把token（仅传输，不存储）传过来，服务端先用token验证用户身份，再执行数据库操作，同时用token完成需要的业务逻辑——触发器只负责数据库内部的操作（比如更新关联数据），不用碰token。

• 用用户唯一标识替代token做触发器逻辑
  如果触发器只需要确认“是哪个用户触发的操作”，那你可以把用户的Facebook唯一ID（这个是安全的，可以存数据库）和数据库操作绑定。触发器基于这个ID做身份关联、权限校验或者数据联动，而token的验证完全在客户端/后端完成，数据库全程不碰敏感的token。

最后再提个安全提醒 #

Facebook的access token（除了长期令牌）都是短期有效，而且是用户身份的核心凭证，绝对别存进数据库！哪怕加密也不行，最优做法是在客户端内存中临时持有，或者存在Android的Keystore安全存储里，只用在需要调用Facebook API的瞬间，用完就及时清理。

内容的提问来源于stack exchange，提问作者Sanyam Raj