fix: validate canLoginWebUi permission in middleware

[ding113]

修复 Bug: key 不允许登陆 web 面板的设置无效

问题描述

• 登录接口正确检查了 canLoginWebUi 权限
• 但中间件只检查 cookie 是否存在，没有重新验证 key 的权限
• 导致用户登录后，管理员修改 canLoginWebUi=false 时，用户仍可访问 dashboard

修复方案

• 在 middleware 中调用 validateKey() 验证完整权限
• 包括 canLoginWebUi、isEnabled、expiresAt 等检查
• 如果验证失败，清除 cookie 并重定向到登录页

Fixes #3

🤖 Generated with Claude Code

[claude]

Claude finished @ding113's task —— View job

---

代码审查完成 ✅

任务清单

• 读取并分析 src/middleware.ts 的变更
• 验证 validateKey() 函数的实现
• 检查安全性和边界情况
• 提供代码审查反馈

---

审查结果：✅ 批准合并

这个 PR 很好地解决了 Issue #3 中描述的安全漏洞。代码质量高，逻辑清晰，修复方案完善。

优点

1. ✅ 准确定位问题

   • 正确识别出中间件只检查 cookie 存在性，未验证实时权限的安全漏洞
   • 修复后确保每次请求都验证 key 的完整权限

2. ✅ 修复方案完善

   • 调用 validateKey() 进行完整的权限检查：
     • canLoginWebUi - Web UI 登录权限
     • isEnabled - Key 是否启用
     • expiresAt - Key 是否过期
     • 用户是否存在且未删除
   • 验证失败时正确清除 cookie 并重定向
   • 保留了 from 参数，用户体验良好

3. ✅ 代码质量

   • 清晰的注释说明修复意图
   • 函数签名正确添加了 async
   • 错误处理逻辑完整（清除 cookie + 重定向）
   • 符合项目现有代码风格

4. ✅ 安全性提升

   • 关闭了权限绕过漏洞
   • 确保管理员修改权限后立即生效
   • 不再依赖 7 天 cookie 过期才生效

技术细节验证

我已验证以下关键点：

1. validateKey() 函数实现正确 (src/lib/auth.ts:17-67)

   • Admin Token 特殊处理（始终允许）
   • 调用 findActiveKeyByKeyString() 检查 key 状态
   • findActiveKeyByKeyString() 已在 SQL 层面过滤：
     • isEnabled = true
     • deletedAt IS NULL
     • expiresAt IS NULL OR expiresAt > NOW()
   • 额外检查 canLoginWebUi 权限
   • 验证关联的 user 是否存在

2. 性能考虑

   • 每次请求都会查询数据库验证权限
   • 对于受保护路由这是必要的安全开销
   • 建议：如果未来流量大，可考虑添加短期缓存（如 30-60 秒），平衡安全性和性能

3. 边界情况处理正确

   • Cookie 不存在 → 重定向登录 ✅
   • Key 无效/过期/禁用 → 清除 cookie + 重定向 ✅
   • 权限验证通过 → 正常访问 ✅

建议（可选）

虽然当前实现已经很好，但如果考虑性能优化，未来可以：

1. 添加短期缓存（仅供参考，不要求本 PR 实现）

   // 可以考虑在 Redis 中缓存 validateKey 结果 30-60 秒
   // 既能及时响应权限变更，又能减少数据库压力
   // 但要权衡安全性（权限变更延迟）和性能

2. 日志记录（仅供参考）

   // 建议在权限验证失败时记录日志，便于监控异常访问
   if (!session) {
     logger.warn('Key validation failed in middleware', { 
       authToken: authToken.value.substring(0, 10) + '...', 
       pathname 
     });
   }

测试建议

建议手动测试以下场景：

1. ✅ 用户正常登录并访问 dashboard
2. ✅ 管理员修改 canLoginWebUi=false，用户刷新页面应立即被登出
3. ✅ 管理员修改 isEnabled=false，用户刷新页面应立即被登出
4. ✅ Key 过期后，用户刷新页面应立即被登出
5. ✅ Admin Token 仍然可以正常访问

总结

这是一个高质量的安全修复 PR，建议立即合并。修复方案简洁有效，没有引入不必要的复杂性，同时解决了多个相关的权限实时性问题。

---