Next SaaS Stripe Starter 项目中的静态页面权限控制问题解析

在 Next.js 项目中实现 SaaS 应用时，权限控制是一个关键环节。Next SaaS Stripe Starter 作为一个优秀的 SaaS 项目模板，采用了中间件(middleware)的方式来实现路由级别的权限控制，但在处理静态生成的页面时出现了一个值得注意的问题。

问题背景

项目中使用 contentlayer 生成的静态页面（如服务条款/privacy、隐私政策/terms等）默认需要用户认证才能访问。这显然不符合常规需求，因为这些页面通常应该是公开的。当未登录用户尝试访问这些页面时，会被重定向到登录页面。

技术原因分析

问题的根源在于项目的中间件实现逻辑。在 middleware.ts 文件中，项目检查用户是否登录，如果未登录且请求的路由不在 publicRoutes 数组中，就会将用户重定向到登录页面。

由于这些静态页面没有像/docs或/guides这样的特定前缀，它们没有被自动识别为公开路由。这导致了一个矛盾：虽然这些页面是静态生成的，理论上应该是公开的，但却被权限系统拦截了。

解决方案探讨

临时解决方案

最直接的解决方法是手动将这些静态页面的路径添加到 publicRoutes 数组中：

export const publicRoutes = [
  // 其他路由...
  "/terms",
  "/privacy",
];

这种方法简单直接，但存在明显的局限性：每次新增静态页面时都需要手动更新这个列表，这违背了静态生成自动化的初衷。

更优的解决方案

从架构设计角度考虑，更合理的解决方案应该是：

1. 路径前缀约定：为所有静态页面设置统一前缀（如/pages），这样可以通过简单的路径匹配规则将其全部纳入公开路由

2. 自动识别机制：开发一个自动扫描 contentlayer 生成页面的脚本，动态更新 publicRoutes

3. 元数据标记：在页面源文件中添加是否公开的元数据标记，构建时自动生成对应的路由配置

4. 默认公开原则：修改中间件逻辑，使静态生成页面默认公开，需要保护的页面才需要特别声明

最佳实践建议

对于类似项目，建议采用以下权限控制策略：

1. 区分动态内容和静态内容，静态内容默认公开
2. 使用路径前缀来分类不同类型的路由
3. 实现自动化配置生成，减少手动维护
4. 在项目文档中明确权限控制策略，方便后续维护

总结

权限控制系统是SaaS应用的核心组件之一，需要在灵活性和便利性之间找到平衡。Next SaaS Stripe Starter项目展示了基于中间件的权限控制实现，同时也揭示了静态内容权限管理中的常见问题。通过合理的架构设计和自动化手段，可以构建出既安全又易于维护的权限控制系统。