Czar.Cms用户权限极简设计角色菜单权限四表联动的设计全过程【免费下载链接】Czar.Cms.NET Core实战项目之CMS系列教程的源码精简而又功能丰富的权限设计内容管理设计让你轻松搭建一个ASP.NET Core2.2的网站系统.此项目准备用EFCore进行重构敬请期待项目地址: https://gitcode.com/gh_mirrors/cz/Czar.CmsCzar.Cms 是一个基于 ASP.NET Core 2.2 的 .NET Core 实战 CMS 项目它的后台权限模块只用了 4 张表——Manager管理员、ManagerRole角色、Menu菜单、RolePermission角色权限就完成了角色 菜单 按钮权限的完整 RBAC 权限设计。本文带你完整拆解这套四表联动的设计全过程新手看完也能直接复用到自己的后台项目里。一、为什么4张表就够一套权限系统很多权限设计一上来就建七八张表用户、用户组、组、角色、菜单、角色菜单、用户菜单……表越多联调越痛苦。Czar.Cms 的取舍是普通用户不直接挂权限只挂一个角色权限全部在角色层面批量管理。表职责模型文件Manager管理员账号一人一个RoleIdManager.csManagerRole角色定义区分超管/系管ManagerRole.csMenu菜单树兼作按钮权限载体Menu.csRolePermission角色 ↔ 菜单 的多对多桥梁RolePermission.cs对应数据库脚本见 CzarCms.sql。下面逐表拆解。二、逐表拆解每张表只干一件事1️⃣ Manager 管理员表一人一角色Manager.cs 中最关键的字段是必填的RoleId——用户表里不存任何权限明细只存一个角色外键。这样给用户调权限变成了给用户换角色一次 UPDATE 搞定。另外两个细节很值得学密码统一用 AES 加密后入库新建账号自动写入加密后的默认密码见 ManagerService.cs自带IsLock锁定、IsDelete软删除、登录次数与最后登录 IP/时间字段一套审计字段直接配齐。2️⃣ ManagerRole 角色表超管与系管分型ManagerRole.cs 里的RoleType区分 1超管、2系管IsSystem标记系统默认角色防止误删。整个角色表只保留了名称、类型、备注和通用审计字段没有任何角色继承角色组这类复杂设计——够用就好。3️⃣ Menu 菜单表菜单和按钮是同一种东西这是全项目最精妙的一张表。Menu.cs 通过ParentId自关联形成无限级菜单树而Permission字段的注释是操作权限按钮权限时使用。也就是说导航菜单是一行新增/删除/导出这类按钮权限又是它下面的子行同一张表、同一条 SQL 就能把看什么菜单 点什么按钮一起查出来完全不需要再发明一张独立的权限表。4️⃣ RolePermission 关联表角色与菜单的桥RolePermission.cs 只有三个业务字段RoleId、MenuId、Permission功能权限。它把角色能看哪些菜单从 Manager 和 Menu 两张表里彻底解耦出来改角色权限不碰用户表改菜单结构不碰角色表。三、四表联动全流程从登录到菜单渲染第 1 步登录校验验证码 错误次数双保险登录入口在 AccountController.cs按顺序做三道拦截Session 验证码比对 → 连续错误超过 3 次直接拒绝 → FluentValidation 参数校验。校验通过后才交给 SignInAsync 做 AES 密码匹配顺便记录登录日志ManagerLog 表链路非常干净。第 2 步把角色写进 Claims后续请求零查库登录成功后Controller 把manager.RoleId作为ClaimTypes.Role连同 Id、头像、昵称等一起塞进 Cookie 身份声明见 AccountController.cs。角色 ID 跟着 Cookie 走之后每次请求都知道我是哪个角色不用再查库。第 3 步一条 SQL 完成角色→权限→菜单联动首页导航数据由 HomeController.GetMenu 提供从 Claims 取出RoleId调用 GetMenusByRoleId底层就是一条 JOIN 查询见 ManagerRoleRepository.csSELECT m.*, rp.Permission FROM RolePermission AS rp INNER JOIN Menu AS m ON rp.MenuId m.Id WHERE rp.RoleId RoleId AND m.IsDelete 0这一步就是四表联动的落点登录时 Manager 表交出 RoleId运行时 RolePermission 表把角色翻译成一串 MenuIdMenu 表给出完整菜单与按钮权限——角色、权限、菜单三张表一次 JOIN 全部到位。第 4 步组装成树形导航返回前端拿到平铺的菜单列表后HomeController.cs 用一个扩展方法GenerateTree(x x.Id, x x.ParentId)把它变成树形 JSONlayui 前端直接渲染出带权限差异的侧边导航。四、分配权限时的事务保障给角色勾选菜单发生在后台角色管理页核心实现在 ManagerRoleRepository.cs新增角色InsertByTrans同一事务里先插角色行再循环插入每条RolePermission任何一步失败整体Rollback修改角色UpdateByTrans采用先 DELETE 该角色全部旧权限 → 再逐条 INSERT 新勾选的全量覆盖策略。策略简单粗暴但配合事务保证了原子性——不会出现角色改了、权限还停在半路的脏数据。对新手来说这比维护增/删差异的实现可靠得多。五、新手可以直接抄的 3 个设计要点用户只挂角色权限按角色批量管理少一张用户-权限中间表用户侧永远是一次 UPDATE菜单表兼任按钮权限靠Permission字段 父子结构一张表同时解决看什么菜单和点什么按钮权限分配用删光重插 事务逻辑最简单、最不易出 bug 的方案。项目还在 PermissionFilter.cs 预留了基于IAsyncAuthorizationFilter的控制器级权限过滤器当前为占位实现说明这套设计预留了向细粒度按钮鉴权演进的出口而 CzarCmsEnums.cs 中的动作枚举也已为操作日志分好类。小结Czar.Cms 用 Manager ManagerRole Menu RolePermission 四张表把登录认证 → 角色身份 → 菜单渲染 → 权限分配整条链路压缩到了最短用户查角色、角色查桥梁、桥梁查菜单一步 JOIN 出全量导航。如果你想给自己的 ASP.NET Core 后台设计一套轻量权限体系这个角色 菜单 权限四表联动的结构是一套非常值得起步参考的极简范式。【免费下载链接】Czar.Cms.NET Core实战项目之CMS系列教程的源码精简而又功能丰富的权限设计内容管理设计让你轻松搭建一个ASP.NET Core2.2的网站系统.此项目准备用EFCore进行重构敬请期待项目地址: https://gitcode.com/gh_mirrors/cz/Czar.Cms创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Czar.Cms用户权限极简设计：角色+菜单+权限四表联动的设计全过程
Czar.Cms用户权限极简设计角色菜单权限四表联动的设计全过程【免费下载链接】Czar.Cms.NET Core实战项目之CMS系列教程的源码精简而又功能丰富的权限设计内容管理设计让你轻松搭建一个ASP.NET Core2.2的网站系统.此项目准备用EFCore进行重构敬请期待项目地址: https://gitcode.com/gh_mirrors/cz/Czar.CmsCzar.Cms 是一个基于 ASP.NET Core 2.2 的 .NET Core 实战 CMS 项目它的后台权限模块只用了 4 张表——Manager管理员、ManagerRole角色、Menu菜单、RolePermission角色权限就完成了角色 菜单 按钮权限的完整 RBAC 权限设计。本文带你完整拆解这套四表联动的设计全过程新手看完也能直接复用到自己的后台项目里。一、为什么4张表就够一套权限系统很多权限设计一上来就建七八张表用户、用户组、组、角色、菜单、角色菜单、用户菜单……表越多联调越痛苦。Czar.Cms 的取舍是普通用户不直接挂权限只挂一个角色权限全部在角色层面批量管理。表职责模型文件Manager管理员账号一人一个RoleIdManager.csManagerRole角色定义区分超管/系管ManagerRole.csMenu菜单树兼作按钮权限载体Menu.csRolePermission角色 ↔ 菜单 的多对多桥梁RolePermission.cs对应数据库脚本见 CzarCms.sql。下面逐表拆解。二、逐表拆解每张表只干一件事1️⃣ Manager 管理员表一人一角色Manager.cs 中最关键的字段是必填的RoleId——用户表里不存任何权限明细只存一个角色外键。这样给用户调权限变成了给用户换角色一次 UPDATE 搞定。另外两个细节很值得学密码统一用 AES 加密后入库新建账号自动写入加密后的默认密码见 ManagerService.cs自带IsLock锁定、IsDelete软删除、登录次数与最后登录 IP/时间字段一套审计字段直接配齐。2️⃣ ManagerRole 角色表超管与系管分型ManagerRole.cs 里的RoleType区分 1超管、2系管IsSystem标记系统默认角色防止误删。整个角色表只保留了名称、类型、备注和通用审计字段没有任何角色继承角色组这类复杂设计——够用就好。3️⃣ Menu 菜单表菜单和按钮是同一种东西这是全项目最精妙的一张表。Menu.cs 通过ParentId自关联形成无限级菜单树而Permission字段的注释是操作权限按钮权限时使用。也就是说导航菜单是一行新增/删除/导出这类按钮权限又是它下面的子行同一张表、同一条 SQL 就能把看什么菜单 点什么按钮一起查出来完全不需要再发明一张独立的权限表。4️⃣ RolePermission 关联表角色与菜单的桥RolePermission.cs 只有三个业务字段RoleId、MenuId、Permission功能权限。它把角色能看哪些菜单从 Manager 和 Menu 两张表里彻底解耦出来改角色权限不碰用户表改菜单结构不碰角色表。三、四表联动全流程从登录到菜单渲染第 1 步登录校验验证码 错误次数双保险登录入口在 AccountController.cs按顺序做三道拦截Session 验证码比对 → 连续错误超过 3 次直接拒绝 → FluentValidation 参数校验。校验通过后才交给 SignInAsync 做 AES 密码匹配顺便记录登录日志ManagerLog 表链路非常干净。第 2 步把角色写进 Claims后续请求零查库登录成功后Controller 把manager.RoleId作为ClaimTypes.Role连同 Id、头像、昵称等一起塞进 Cookie 身份声明见 AccountController.cs。角色 ID 跟着 Cookie 走之后每次请求都知道我是哪个角色不用再查库。第 3 步一条 SQL 完成角色→权限→菜单联动首页导航数据由 HomeController.GetMenu 提供从 Claims 取出RoleId调用 GetMenusByRoleId底层就是一条 JOIN 查询见 ManagerRoleRepository.csSELECT m.*, rp.Permission FROM RolePermission AS rp INNER JOIN Menu AS m ON rp.MenuId m.Id WHERE rp.RoleId RoleId AND m.IsDelete 0这一步就是四表联动的落点登录时 Manager 表交出 RoleId运行时 RolePermission 表把角色翻译成一串 MenuIdMenu 表给出完整菜单与按钮权限——角色、权限、菜单三张表一次 JOIN 全部到位。第 4 步组装成树形导航返回前端拿到平铺的菜单列表后HomeController.cs 用一个扩展方法GenerateTree(x x.Id, x x.ParentId)把它变成树形 JSONlayui 前端直接渲染出带权限差异的侧边导航。四、分配权限时的事务保障给角色勾选菜单发生在后台角色管理页核心实现在 ManagerRoleRepository.cs新增角色InsertByTrans同一事务里先插角色行再循环插入每条RolePermission任何一步失败整体Rollback修改角色UpdateByTrans采用先 DELETE 该角色全部旧权限 → 再逐条 INSERT 新勾选的全量覆盖策略。策略简单粗暴但配合事务保证了原子性——不会出现角色改了、权限还停在半路的脏数据。对新手来说这比维护增/删差异的实现可靠得多。五、新手可以直接抄的 3 个设计要点用户只挂角色权限按角色批量管理少一张用户-权限中间表用户侧永远是一次 UPDATE菜单表兼任按钮权限靠Permission字段 父子结构一张表同时解决看什么菜单和点什么按钮权限分配用删光重插 事务逻辑最简单、最不易出 bug 的方案。项目还在 PermissionFilter.cs 预留了基于IAsyncAuthorizationFilter的控制器级权限过滤器当前为占位实现说明这套设计预留了向细粒度按钮鉴权演进的出口而 CzarCmsEnums.cs 中的动作枚举也已为操作日志分好类。小结Czar.Cms 用 Manager ManagerRole Menu RolePermission 四张表把登录认证 → 角色身份 → 菜单渲染 → 权限分配整条链路压缩到了最短用户查角色、角色查桥梁、桥梁查菜单一步 JOIN 出全量导航。如果你想给自己的 ASP.NET Core 后台设计一套轻量权限体系这个角色 菜单 权限四表联动的结构是一套非常值得起步参考的极简范式。【免费下载链接】Czar.Cms.NET Core实战项目之CMS系列教程的源码精简而又功能丰富的权限设计内容管理设计让你轻松搭建一个ASP.NET Core2.2的网站系统.此项目准备用EFCore进行重构敬请期待项目地址: https://gitcode.com/gh_mirrors/cz/Czar.Cms创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考