Remult框架中实现访客专属API的权限控制方案

在Remult框架的权限控制体系中，开发者经常需要处理一些仅允许未认证用户（访客）访问的特殊API端点。这类需求常见于用户注册、登录和密码找回等功能场景，这些操作显然不应该对已经通过身份验证的用户开放。

核心需求分析

传统权限控制通常关注的是"允许谁访问"，而访客专属API则需要实现"禁止谁访问"的反向逻辑。具体表现为：

• 注册接口（Auth.register）
• 登录接口（Auth.login）
• 密码找回接口（Auth.forgotPassword）

这些接口的业务逻辑决定了它们应该：

1. 允许未携带有效凭证的请求通过
2. 拒绝已认证用户的访问请求

技术实现方案

Remult框架本身提供了Allow.authenticated装饰器用于要求认证，但缺乏直接的"仅限访客"控制方案。通过组合现有功能，我们可以构建出优雅的解决方案：

function guestOnly() {
  return !Allow.authenticated()
}

@BackendMethod({ allowed: guestOnly })
async register(userData: UserDTO) {
  // 注册逻辑
}

设计考量

在命名规范上，有几个备选方案值得考虑：

1. notAuthenticated - 直接表达逻辑否定
2. guestOnly - 强调专属特性
3. allowAnonymous - 从允许角度描述

从框架设计哲学来看，notAuthenticated更符合Remult现有的Allow.authenticated命名风格，保持了API的一致性。这种实现方式也体现了"组合优于继承"的设计原则，通过简单组合现有功能实现新特性，而不需要修改框架核心。

实际应用建议

在实际项目中，建议将这些权限控制函数集中管理：

// auth-utils.ts
export const AuthRules = {
  guestOnly: () => !Allow.authenticated(),
  adminOnly: () => Allow.authenticated().and(hasRole('admin'))
}

这种组织方式可以：

• 保持权限逻辑的一致性
• 方便全局修改权限策略
• 提高代码可读性
• 便于进行单元测试

安全注意事项

实现访客专属API时需要特别注意：

1. 应该在服务端和客户端都进行权限验证
2. 对于敏感操作（如密码重置）应该增加额外的验证机制
3. 考虑添加访问频率限制防止恶意尝试
4. 记录异常访问尝试

Remult的这种权限控制方式为开发者提供了灵活的安全控制能力，通过合理组合可以满足各种复杂的业务场景需求。