role-enforcement-fullstack

用途：在前后端实现端到端 RBAC（基于角色的访问控制），用共享权限模型避免前后端权限逻辑重复与漂移，并规避假安全或破坏用户体验的陷阱。资料明确说明它跳过基础鉴权搭建，假定用户对象上已存在角色。\n\n主要能力：围绕七个核心模式展开。一是单一事实来源：用共享 PERMISSIONS 映射与 can() 函数，无法共享代码时从后端构建期生成前端映射，绝不手工维护两份。二是后端强制：区分路由级中间件（粗粒度、仅凭角色拒绝）与处理函数内的资源级检查（如“是否为本人帖子”）。三是前端路由守卫：给出 React Router v6 的 ProtectedRoute 组件与 Next.js App Router 的 middleware.ts 示例。四是 UI 门控：用 usePermission 钩子隐藏元素，强调不要直接用角色字符串比较。五是 JWT 声明与数据库角色的取舍（快但有过期风险、实时但增加延迟、混合方案加缓存失效），并给出角色变更后使令牌失效的缓存校验思路。六是 tRPC/GraphQL 在解析器或过程级别检查权限，GraphQL 可对未授权字段返回 null。七是 403 与 404 的选择：对用户不应知晓存在的资源返回 404 以防信息泄露。\n\n使用方式：资料给出可产出的文件清单 permissions.ts、requireRole.ts、ProtectedRoute.tsx 或 middleware.ts、usePermission.ts，每个文件需注释说明强制了什么、刻意不强制什么（安全边界还是 UX 边界）、单一事实来源位置。开始前需回答发现性问题：权限模型是扁平还是层级、角色来源是 JWT 声明还是每请求数据库查询或会话对象、是否 monorepo 可共享模块、前端框架与后端框架、所需粒度是路由级还是字段级。\n\n适用场景与限制：适用于为已有角色的 Web 应用补齐前后端权限一致性。资料提醒前端门控只是 UX，后端检查才是安全；Next.js middleware 运行在 Edge 运行时，不能用 Node.js API 或访问数据库，角色必须放在 cookie/令牌中而非实时查询。资料未提供具体安装命令、依赖版本、价格与平台信息。