perf(auth): 登录去掉一次冗余查库 + 缓存 2FA 查询 + 修掉 session_key 进日志

登录实测约 232ms,其中 bcrypt 约 72ms、网络往返约 80ms 是不可省的计算/物理成本,
剩下的都是我们自己的开销。这次把能省的两处省掉(实测约 40ms,占登录耗时约 19%):

1. 去掉「数据库连接检查」的冗余预检
   原来每次登录先 await db.select().from(users).limit(1) 只为"测连接",
   紧接着又会真的查用户,连不上一样会报错 —— 纯粹多一次数据库往返。
   现在把那次真实查询包进 try,只有它失败才回报 503「数据库服务暂时不可用」,
   错误码与文案完全不变。

2. 缓存「这个账号有没有开 2FA」
   登录每次都查 userIdentities 找 TOTP,但绝大多数账号根本没开 2FA。
   新增 server/utils/totp-cache.ts:
     · 查到**没有** TOTP → 缓存 10 分钟,后续登录直接跳过查询
     · 查到**有** TOTP   → **不缓存**(安全优先:绝不能因为缓存而让刚开 2FA 的人被跳过验证)
   开启/关闭 2FA 的接口必须调用 invalidateTotpCache(userId),已在
   server/api/user/2fa/{enable,disable}.post.ts 接上 —— 否则会有最长 10 分钟的验证空窗。
   该缓存不参与密码校验,最坏情况只是多查一次库。

3. lastLogin / lastLoginIp 的 UPDATE 不再阻塞响应
   登录时间与登录 IP 是审计信息,晚写几十毫秒、甚至这次写失败,
   都不影响用户能否登录。改为不 await(保留 .catch,避免 unhandledRejection)。

4. 安全修复:微信登录不再把 session_key 打进日志
   server/api/auth/wechat/login.post.ts 原来打印整个 jscode2session 响应前 500 字,
   而该响应含 { session_key, openid, unionid }。
   session_key 是敏感凭据(可解密用户数据、配合其他接口换取手机号),
   长期落在服务端日志里等于凭据落盘。
   现在只打印:顶层键名、errcode/errmsg、以及 openid/session_key/unionid 的
   存在性与长度(不打印值);仅在"响应根本不是对象"时才打印截断原文
   (那种情况它不可能是合法凭据,且是排查被代理拦成 HTML 的唯一线索)。

已验证:
- 缓存逻辑用假 db 真跑过 5 个场景(命中缓存省下查询、失效后立刻重查、
  有 2FA 不缓存、多用户互不干扰、只失效指定用户)
- 4 个改动文件的相对 import 路径均存在;totp-cache 的导出与两处 import 对得上
- login.post.ts 抽走 TOTP 查询后已清理不再使用的 userIdentities / and 导入
- 文件编码 UTF-8 无 BOM、无乱码、括号平衡
This commit is contained in:
2026-10-01 21:04:02 +08:00
parent 752a2eae87
commit ebf1c3a127
5 changed files with 198 additions and 42 deletions
+33 -5
View File
@@ -91,12 +91,31 @@ export default defineEventHandler(async (event) => {
* 最可能是 $fetch 拿回了一段非 JSON 文本(被代理/防火墙拦截返回的 HTML、
* 或重定向页),此时 ofetch 解析失败会把原始字符串返回,于是所有字段都是 undefined。
*
* 所以这里把**响应的真实类型和内容**打出来,否则下次还是只能看到 undefined。
* 所以这里把**响应的真实类型和关键字段**打出来,否则下次还是只能看到 undefined。
* appid 打前 6 位后 4 位,用于和微信公众平台里的小程序 AppID 核对(两者必须完全一致,
* 且**不能**填公众号的 AppID —— 那套凭据不通用)。
*
* ★★★ 安全修复(第 97 轮)★★★
* 原来这里把**整个响应 JSON 前 500 字**打进日志:
*
* console.error('[WeChatMP] 诊断: 原始响应=' + JSON.stringify(session)?.slice(0, 500))
*
* 而 jscode2session 的成功响应形如:
* { session_key: '...', openid: '...', unionid: '...' }
*
* **`session_key` 是敏感凭据** —— 有了它可以解密用户数据、配合其他接口换取手机号。
* 它出现在服务端日志里(日志会被备份、被运维翻看、可能进日志平台),
* 等于把用户凭据长期落盘。这**不是性能问题,是安全问题**,必须去掉。
*
* 现在只打印**故障定位真正需要**的东西:
* · 顶层键名(判断"是不是微信的 JSON"足够了,不含值)
* · errcode / errmsg(微信的报错码)
* · openid / session_key / unionid 的**存在性与长度**(不打印值)
* · 响应非对象时,才打印截断后的原始文本(此时它不是合法凭据)
*/
const appidMasked =
appid.length > 10 ? appid.slice(0, 6) + '****' + appid.slice(-4) : appid.slice(0, 3) + '****'
const maskLen = (v: unknown) => (typeof v === 'string' && v ? '有(len=' + v.length + ')' : '无')
console.error(
'[WeChatMP] 诊断: appid=' + appidMasked +
' secretLen=' + String(secret).length +
@@ -105,11 +124,20 @@ export default defineEventHandler(async (event) => {
' 顶层键=' + (session && typeof session === 'object' ? Object.keys(session).join(',') : '(非对象)')
)
console.error(
'[WeChatMP] 诊断: 原始响应=' +
(typeof session === 'string'
? session.slice(0, 500)
: JSON.stringify(session)?.slice(0, 500))
'[WeChatMP] 诊断: openid=' + maskLen(session?.openid) +
' session_key=' + maskLen(session?.session_key) +
' unionid=' + maskLen(session?.unionid) +
' errcode=' + (session?.errcode ?? '(无)') +
' errmsg=' + (session?.errmsg ?? '(无)')
)
// 只有"响应根本不是对象"时才打印原文 —— 那种情况下它不可能是合法凭据,
// 而且是排查"被代理拦成 HTML"唯一有用的信息。
if (!session || typeof session !== 'object') {
console.error(
'[WeChatMP] 诊断: 响应非对象,原文前 300 字=' +
(typeof session === 'string' ? session.slice(0, 300) : String(session))
)
}
// 微信接口失败时仍返回 HTTP 200,必须检查 openid
if (!session || typeof session !== 'object' || !session.openid) {