各位朋友好又见面了我们来简单回顾一下上次做了什么我们基本实现了一个简单的认证功能包括前台的登入页面前后的相互交互 并完成了后端的认证我相信大多数有经验的小伙伴一定知道后面我会去实现权限控制的功能其实我原本可以直接在认证开始就带着权限功能一起实现如果你知道在认证开始就要想着如何设计权限认证功能那么是你的经验和财富。但是我相信看到这篇文章的人并不全部都是经验丰富的开发者所以我选择实现一个并不完整功能然后在一点点完善。这也是我想和很多没有那么资深的开发者表达的当你面对一个全新位置的功能一开始就去实现一个完善的功能是不现实的去过多的思考功能的完善程度只能阻碍你去放手去做的信息所有的工程化的方法思路都是一开始想要去完成一个目标并将分为各个不同的小目标在完成一个不同小目标的过程中不断去修正你的方法和思路去跨过一个又一个阶段最终达成一个结果。当然这个结果可能和你一开始的目标并不相同可能更好也可能更坏。但是这个过程中的经验和教训才是你的财富。这个工程的话思想使用于所有长期去做的事情无论是工作学习亦或者健身运动甚至是人生。好了私货夹带的有点对了那么我们赶紧开始我们的下一步工作如果你并没有思路和头绪不妨在借助ai,以下是我的关键词当我已经有基于jwt的认证功能我想在加入权限控制功能如何加入 给我个解决方案即可。相信如果你非常了解关键词你可能会认为我的关键词非常的业余既没有角色的定义也没有具体的规则但是我在这里会继续提起我在上篇文章结尾说到的提示语范式相信模型的智能多做引导而非指定规则。基于您已有的JWT认证功能要加入权限控制功能需要构建一个完整的基于角色的访问控制RBAC系统。以下是结合多个最佳实践的综合解决方案一、后端权限控制架构设计1. 定义细粒度权限模型首先需要建立清晰的权限模型这是权限控制的基础。创建权限枚举和角色枚举类实现权限的细粒度控制。权限枚举定义具体的操作权限如user:read、user:write角色枚举则组合这些权限并为每个角色生成对应的权限集合。这种设计支持方法级的权限控制比简单的角色控制更加灵活和安全。2. 增强用户实体与JWT令牌修改现有的用户实体类使其实现Spring Security的UserDetails接口并包含角色信息。在生成JWT令牌时需要包含用户的角色和权限信息这样在后续的请求中可以直接从令牌中解析出用户的权限无需频繁查询数据库。同时在UserDetailsService的实现中需要正确加载用户的权限集合确保Spring Security能够识别用户的权限。3. 配置Spring Security权限规则在安全配置中定义细粒度的权限控制规则。Spring Security 6.0采用了新的配置范式摒弃了WebSecurityConfigurerAdapter转而使用Lambda DSL与组件化配置模式。通过SecurityFilterChainBean的定义可以实现更清晰的配置分离。配置应包括公开接口的访问权限基于HTTP方法和权限的细粒度控制基于角色的访问控制启用方法级权限控制注解支持4. 实现方法级权限控制使用PreAuthorize注解在控制器方法上实现更细粒度的权限控制。这种方法允许在方法级别定义访问规则如PreAuthorize(hasAuthority(user:read) or hasAuthority(admin:read))。确保在SecurityConfig中启用EnableMethodSecurity注解以支持方法级的安全控制。二、前端权限控制实现1. 存储用户权限信息登录成功后前端需要保存用户的角色和权限信息到本地存储如localStorage或sessionStorage。这些信息包括用户ID、用户名、角色和权限列表用于后续的权限验证和界面控制。2. 实现路由守卫在前端路由中实现基于权限的路由守卫控制用户能否访问某个页面。路由守卫应检查用户是否已登录检查token是否存在用户是否有访问该路由所需的权限用户是否有访问该路由所需的角色对于无权限的访问应重定向到403页面或登录页面。3. 实现按钮级权限控制在前端组件中实现按钮级别的权限控制根据用户的权限动态显示或隐藏功能按钮。这可以通过自定义指令或组件封装实现确保用户只能看到和操作自己有权限的功能。三、权限控制层级体系完整的权限控制应包含四个层级1. 路由权限控制控制用户能否访问某个页面通过前端路由守卫实现。2. 菜单权限控制根据用户角色和权限动态生成可访问的菜单项确保用户只能看到自己有权限访问的菜单。3. 按钮权限控制控制页面内具体功能按钮的显示与隐藏实现界面级的权限控制。4. 接口权限控制后端API接口的权限验证确保即使前端绕过检查后端也会拒绝未授权的请求。这是最后一道防线也是最重要的安全保证。四、高级功能增强1. Token自动续期机制每次成功访问受保护接口时过滤器判断Token剩余时间是否低于阈值如10分钟如果是则自动签发新Token并通过响应头返回。前端监听该响应头并自动更新本地Token实现无感知的Token续期。2. Token黑名单机制用户退出登录时将当前Token加入黑名单可用Redis设置自动过期。在过滤器中拒绝黑名单内的Token确保退出登录后Token立即失效。黑名单使用Redis TTL自动过期无需手动清理。3. 动态权限决策自定义AccessDecisionManager集成业务规则引擎实现基于时间、IP等维度的动态授权。例如可以限制某些敏感操作只能在特定时间段或特定IP地址下执行。4. 权限数据动态管理考虑将角色和权限信息存储在数据库中实现动态配置。这样可以在不重启应用的情况下修改权限分配支持更灵活的业务需求。五、安全优化与性能考虑1. 签名算法选择根据部署架构选择合适的签名算法HMAC算法适用于单节点部署签名速度快但密钥分发复杂RSA算法通过公私钥对实现令牌签发与验证适合微服务架构下的分布式验证。2. 高并发场景优化在高并发场景下可以采用以下策略优化性能令牌解析缓存对频繁访问的JWT载荷进行本地缓存减少重复解析开销异步非阻塞验证结合WebFlux通过ServerHttpSecurity实现非阻塞式令牌验证3. 统一异常处理自定义异常处理器统一处理认证和授权异常返回规范的JSON格式错误信息。包括未登录或无效Token401权限不足403登录失败401六、实施步骤建议评估现有系统分析现有的JWT认证实现确定需要修改的部分设计权限模型根据业务需求设计角色和权限体系后端改造依次实现权限模型、增强用户实体、配置Security、实现方法级控制前端改造实现路由守卫、菜单控制、按钮控制高级功能集成根据需要添加Token续期、黑名单等高级功能测试验证编写全面的测试用例验证权限控制的正确性监控审计添加权限相关的日志记录便于审计和问题排查通过以上方案您可以在现有的JWT认证基础上构建一个完整、安全、可扩展的权限控制系统。这个系统不仅能够满足基本的权限控制需求还支持高级功能如动态权限管理、令牌刷新和黑名单机制为企业级应用提供了坚实的安全基础那么我们看我们的ai给了我们一个什么样的回复基于上面的内容我给大家分析下我的提示词生成逻辑。首先看后端1. 定义细粒度权限模型首先需要建立清晰的权限模型这是权限控制的基础。创建权限枚举和角色枚举类实现权限的细粒度控制。权限枚举定义具体的操作权限如user:read、user:write角色枚举则组合这些权限并为每个角色生成对应的权限集合。这种设计支持方法级的权限控制比简单的角色控制更加灵活和安全。1.生成用户角色权限的关系表和对应关系其中用户可以有多个角色一个角色可以有多个权限。2. 增强用户实体与JWT令牌修改现有的用户实体类使其实现Spring Security的UserDetails接口并包含角色信息。在生成JWT令牌时需要包含用户的角色和权限信息这样在后续的请求中可以直接从令牌中解析出用户的权限无需频繁查询数据库。同时在UserDetailsService的实现中需要正确加载用户的权限集合确保Spring Security能够识别用户的权限。3. 配置Spring Security权限规则在安全配置中定义细粒度的权限控制规则。Spring Security 6.0采用了新的配置范式摒弃了WebSecurityConfigurerAdapter转而使用Lambda DSL与组件化配置模式。通过SecurityFilterChainBean的定义可以实现更清晰的配置分离。配置应包括公开接口的访问权限基于HTTP方法和权限的细粒度控制基于角色的访问控制启用方法级权限控制注解支持4. 实现方法级权限控制使用PreAuthorize注解在控制器方法上实现更细粒度的权限控制。这种方法允许在方法级别定义访问规则如PreAuthorize(hasAuthority(user:read) or hasAuthority(admin:read))。确保在SecurityConfig中启用EnableMethodSecurity注解以支持方法级的安全控制。2.引入Spring Security在生成JWT令牌时需要包含用户的角色和权限信息这样在后续的请求中可以直接从令牌中解析出用户的权限无需频繁查询数据库。同时在UserDetailsService的实现中需要正确加载用户的权限集合确保Spring Security能够识别用户的权限。我们使用ai帮我生成了代码同时ai还贴心的给我们生成了一个说明真是我的好牛马# 用户角色权限系统实现说明 ## 概述 本系统实现了基于 Spring Security 的用户角色权限RBAC管理系统支持 - 用户-角色-权限的多对多关系 - JWT 令牌中包含用户角色和权限信息 - 从 JWT 令牌中解析权限无需频繁查询数据库 - Spring Security 方法级权限控制 ## 数据库表结构 ### 主要表 1. **sys_user** - 用户表已存在 2. **sys_role** - 角色表 3. **sys_permission** - 权限表 4. **sys_user_role** - 用户角色关联表 5. **sys_role_permission** - 角色权限关联表 ### 表关系 - 一个用户可以有多个角色sys_user_role - 一个角色可以有多个权限sys_role_permission - 通过角色间接实现用户和权限的多对多关系 ## 实体类 ### 新增实体 - Role.java - 角色实体 - Permission.java - 权限实体 - UserRole.java - 用户角色关联实体 - RolePermission.java - 角色权限关联实体 ### 修改实体 - User.java - 添加了 roles 属性 ## 核心组件 ### 1. CustomUserDetails com.documentagent.gateway.domain.user.security.CustomUserDetails - 实现 Spring Security 的 UserDetails 接口 - 包含用户、角色、权限信息 - 提供权限集合供 Spring Security 使用 ### 2. CustomUserDetailsService com.documentagent.gateway.application.service.CustomUserDetailsService - 实现 Spring Security 的 UserDetailsService 接口 - 加载用户的角色和权限信息 - 提供基于用户名和用户ID的加载方法 ### 3. JwtUtil com.documentagent.gateway.common.util.JwtUtil **修改内容** - generateToken() 方法现在支持角色和权限参数 - 新增 getRolesFromToken() 方法 - 新增 getPermissionsFromToken() 方法 **使用示例** java String token jwtUtil.generateToken(userId, username, roles, permissions); ListString roles jwtUtil.getRolesFromToken(token); ListString permissions jwtUtil.getPermissionsFromToken(token); ### 4. JwtAuthenticationFilter com.documentagent.gateway.common.filter.JwtAuthenticationFilter **功能** - 从请求中提取 JWT 令牌 - 验证令牌有效性 - 从令牌中解析角色和权限信息 - 设置 Spring Security 上下文 ### 5. SecurityConfig com.documentagent.gateway.infrastructure.config.SecurityConfig **配置内容** - 启用 Web 安全 - 启用方法级安全PreAuthorize 等注解 - 配置 JWT 认证过滤器 - 配置密码编码器BCrypt - 配置无需认证的路径 ## JWT 令牌结构 json { userId: 1, username: admin, roles: [ROLE_ADMIN, ROLE_USER], permissions: [document:read, document:write], iat: 1234567890, exp: 1234654290 } ## 工具类 ### SecurityUtils com.documentagent.gateway.common.util.SecurityUtils 提供静态方法获取当前用户信息 java CustomUserDetails user SecurityUtils.getCurrentUser(); Long userId SecurityUtils.getCurrentUserId(); String username SecurityUtils.getCurrentUsername(); boolean isAuth SecurityUtils.isAuthenticated(); ### RequestUtils com.documentagent.gateway.common.util.RequestUtils 从 HttpServletRequest 中获取用户信息 java Long userId RequestUtils.getUserIdFromRequest(request); ListString roles RequestUtils.getRolesFromRequest(request); ListString permissions RequestUtils.getPermissionsFromRequest(request); ## 注解 ### RequiresPermission com.documentagent.gateway.common.annotation.RequiresPermission 方法级权限检查 java RequiresPermission(document:write) public void createDocument(Document document) { // 只有拥有 document:write 权限的用户才能执行 } ### RequiresRole com.documentagent.gateway.common.annotation.RequiresRole 方法级角色检查 java RequiresRole(ROLE_ADMIN) public void deleteUser(Long userId) { // 只有管理员才能执行 } ## 使用示例 ### 登录时生成包含权限的令牌 java Autowired private CustomUserDetailsService userDetailsService; public LoginResponse login(LoginRequest request) { User user userMapper.selectOne(...); CustomUserDetails userDetails userDetailsService.loadUserById(user.getId()); ListString roles userDetails.getAuthorities().stream() .map(GrantedAuthority::getAuthority) .filter(auth - auth.startsWith(ROLE_)) .collect(Collectors.toList()); ListString permissions userDetails.getAuthorities().stream() .map(GrantedAuthority::getAuthority) .filter(auth - !auth.startsWith(ROLE_)) .collect(Collectors.toList()); String token jwtUtil.generateToken(user.getId(), user.getUsername(), roles, permissions); return new LoginResponse(token, user.getId(), user.getUsername(), user.getEmail(), roles, permissions); } ### 方法级权限控制 java RestController RequestMapping(/documents) public class DocumentController { GetMapping(/{id}) PreAuthorize(hasAuthority(document:read)) public Document getDocument(PathVariable Long id) { // 只有拥有 document:read 权限的用户才能访问 } PostMapping PreAuthorize(hasAnyRole(ADMIN, DOC_ADMIN)) public Document createDocument(RequestBody DocumentCreateCommand command) { // 只有 ADMIN 或 DOC_ADMIN 角色的用户才能访问 } DeleteMapping(/{id}) PreAuthorize(hasRole(ADMIN)) public void deleteDocument(PathVariable Long id) { // 只有 ADMIN 角色的用户才能访问 } } ## 数据库初始化 执行 resources/db/schema_rbac.sql 脚本创建表结构和初始化数据。 ### 默认角色 1. **ROLE_ADMIN** - 超级管理员拥有所有权限 2. **ROLE_USER** - 普通用户部分文档权限 3. **ROLE_DOC_ADMIN** - 文档管理员文档管理所有权限 ### 默认权限 - **系统管理**用户管理、角色管理、权限管理 - **文档管理**查看、创建、编辑、删除 - **API权限**文档API、版本API、用户API ## 注意事项 1. **密码迁移**原有系统使用 MD5 加密新系统使用 BCrypt。需要为现有用户更新密码。 2. **令牌刷新**用户权限变更后需要重新登录或刷新令牌。 3. **性能优化**JWT 令牌中包含权限信息减少了数据库查询但需要注意令牌大小。 4. **安全建议** - 生产环境应使用更长的 JWT 密钥 - 敏感操作建议结合数据库权限验证 - 定期更换 JWT 密钥 ## 下一步 1. 创建角色管理 API 2. 创建权限管理 API 3. 创建用户角色分配 API 4. 添加权限变更通知机制 5. 实现细粒度的数据权限控制ok,我们完成了权限的功能回顾这个一切来的简直困难笑但是一起都是值得的但是这依旧存在这个问题存在什么问题呢我相信聪明的你已经看出了没错使用方式在我们的这套解决方案上如何去做权限的变化呢不好意思只能进行编码的修改这可不行总不能给用户设置个权限就修改一次代码吧这不是玩傻子吗我们需要能动态修改权限的功能但是有点困难呢别担心我们有最好的伙伴。PostMapping PreAuthorize(hasAnyRole(ADMIN, DOC_ADMIN)) public Document createDocument(RequestBody DocumentCreateCommand command) { // 只有 ADMIN 或 DOC_ADMIN 角色的用户才能访问 } 如果我的角色变成可配置如何去做这是我们的提示语甚至这都不算提示语只是一个简单的问题其实现阶段我们并不需要负责的提示语来帮助我们引导ai做东西因为我们写的还是java工程如果换到ai应用的部分我们可能就需要好好琢磨我们的提示语了当时这些事我们后续再谈。基于您的代码片段和问题要实现角色的动态可配置化核心思路是将硬编码在注解中的角色信息如ADMIN, DOC_ADMIN转移到外部数据源如数据库并在运行时根据这些配置进行权限决策。以下是实现此目标的几种主要方案结合了搜索结果中的最佳实践。方案一基于数据库的动态URL权限规则推荐用于接口级控制此方案的核心是自定义FilterInvocationSecurityMetadataSource它允许您根据数据库中的配置动态决定每个URL如您的PostMapping端点需要哪些角色才能访问。数据库设计您需要在现有用户、角色表的基础上增加资源表和资源-角色关联表。资源表存储系统中的受保护资源通常包括资源ID、URL模式如/api/documents、资源名称等字段。资源-角色关联表建立资源与角色之间的多对多关系定义访问某个URL模式需要具备哪些角色。自定义安全元数据源实现FilterInvocationSecurityMetadataSource接口重写其getAttributes方法。此方法会在每次请求时被调用用于根据当前请求的URL从数据库中查询出访问该URL所需的所有角色。javaComponent public class DynamicSecurityMetadataSource implements FilterInvocationSecurityMetadataSource { Autowired private ResourceService resourceService; // 您的服务用于查询数据库 private AntPathMatcher antPathMatcher new AntPathMatcher(); Override public CollectionConfigAttribute getAttributes(Object object) throws IllegalArgumentException { String requestUrl ((FilterInvocation) object).getRequestUrl(); // 1. 从数据库或缓存中查询所有“URL模式-所需角色”的配置 ListResource allResources resourceService.getAllResourcesWithRoles(); // 2. 匹配当前请求的URL for (Resource resource : allResources) { if (antPathMatcher.match(resource.getUrlPattern(), requestUrl)) { // 3. 返回该URL所需角色的集合 ListString roleNames resource.getRequiredRoles().stream() .map(Role::getName) .collect(Collectors.toList()); return SecurityConfig.createList(roleNames.toArray(new String); } } // 4. 如果没有匹配到规则可以返回一个默认角色如要求登录或抛出异常 return SecurityConfig.createList(ROLE_LOGIN); } // ... 其他必须实现的方法 }集成到Spring Security配置在您的安全配置类如WebSecurityConfig中通过withObjectPostProcessor方法将自定义的DynamicSecurityMetadataSource和对应的AccessDecisionManager注入到安全过滤器链中。javaConfiguration EnableWebSecurity public class SecurityConfig { Autowired private DynamicSecurityMetadataSource dynamicSecurityMetadataSource; Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .authorizeHttpRequests(authorize - authorize .anyRequest().authenticated() .withObjectPostProcessor(new ObjectPostProcessorFilterSecurityInterceptor() { Override public O extends FilterSecurityInterceptor O postProcess(O interceptor) { interceptor.setSecurityMetadataSource(dynamicSecurityMetadataSource); // 可以同时设置自定义的AccessDecisionManager // interceptor.setAccessDecisionManager(customAccessDecisionManager); return interceptor; } }) ) // ... 其他配置表单登录、CSRF等 ; return http.build(); } }效果完成以上步骤后您就可以通过管理界面或直接操作数据库动态地配置某个API接口如创建文档的接口允许哪些角色访问而无需修改PreAuthorize注解或重新部署代码。方案二结合方法级注解与动态数据源更灵活如果您希望保留PreAuthorize注解的灵活性同时实现动态配置可以创建一个自定义的权限评估器。创建自定义权限表达式实现Spring Security的PermissionEvaluator接口或创建自定义的SPEL表达式函数。javaComponent(docPermissionEvaluator) public class DocumentPermissionEvaluator { Autowired private RoleConfigService roleConfigService; public boolean hasPermission(Authentication authentication, String resourceKey) { // 1. 获取当前用户的所有角色 SetString userRoles authentication.getAuthorities().stream() .map(GrantedAuthority::getAuthority) .collect(Collectors.toSet()); // 2. 根据 resourceKey如 CREATE_DOCUMENT从数据库查询允许的角色 SetString allowedRoles roleConfigService.getAllowedRolesForResource(resourceKey); // 3. 判断用户角色与允许角色是否有交集 return !Collections.disjoint(userRoles, allowedRoles); } }在配置中暴露Bean并用于SPEL在安全配置中暴露该评估器并在PreAuthorize注解中使用。javaConfiguration EnableGlobalMethodSecurity(prePostEnabled true) public class MethodSecurityConfig extends GlobalMethodSecurityConfiguration { Autowired private DocumentPermissionEvaluator docPermissionEvaluator; Override protected MethodSecurityExpressionHandler createExpressionHandler() { DefaultMethodSecurityExpressionHandler expressionHandler new DefaultMethodSecurityExpressionHandler(); // 注册自定义的权限评估器 expressionHandler.setPermissionEvaluator(docPermissionEvaluator); // 也可以将评估器直接注册为根对象以便在SPEL中直接调用 expressionHandler.setRootObject(new SecurityExpressionRootMethods(docPermissionEvaluator)); return expressionHandler; } }然后修改您的控制器方法注解javaPostMapping PreAuthorize(docPermissionEvaluator.hasPermission(authentication, CREATE_DOCUMENT)) public Document createDocument(RequestBody DocumentCreateCommand command) { // 权限逻辑由评估器动态决定 }效果权限规则CREATE_DOCUMENT资源允许哪些角色存储在数据库中可通过管理界面配置。方案三实现动态角色继承如果您的需求包括角色之间的动态继承关系例如SENIOR_ADMIN自动拥有ADMIN的所有权限可以使用Spring Security的RoleHierarchy。从数据库加载继承关系将角色继承关系如ROLE_SENIOR_ADMIN ROLE_ADMIN ROLE_USER存储在数据库中。javaBean public RoleHierarchy roleHierarchy() { RoleHierarchyImpl roleHierarchy new RoleHierarchyImpl(); // 从数据库或配置中心动态获取继承关系字符串 String hierarchy roleService.getRoleHierarchyAsString(); roleHierarchy.setHierarchy(hierarchy); return roleHierarchy; }在安全配置中启用配置了RoleHierarchyBean后Spring Security在检查hasRole(ADMIN)时会自动认为拥有SENIOR_ADMIN角色的用户也满足条件。总结与建议对于您的具体场景使PostMapping接口的角色可配置方案一动态URL权限是最直接、最符合Spring Security原生命令式配置风格的解决方案它彻底将角色与接口的绑定关系外置。方案二自定义表达式提供了更细粒度的控制适合资源键resourceKey与业务逻辑紧密耦合的复杂场景。方案三角色继承可以作为上述方案的补充用于简化角色权限的管理避免为高级角色重复配置所有低级角色的权限。性能优化无论采用哪种方案频繁查询数据库都会成为性能瓶颈。务必在用户登录认证成功后将其角色/权限信息缓存起来如存储在Redis或SecurityContext中在权限校验时直接从缓存读取避免每次请求都访问数据库。管理界面为了实现真正的“可配置”您需要配套开发一个角色和权限的管理界面允许系统管理员通过UI界面而非直接操作数据库来为用户分配角色、为接口资源绑定角色。通过实施上述任一方案您就可以将代码中硬编码的角色依赖解耦实现灵活、可动态配置的权限管理系统。这是ai给我们的回答你可以看到ai给了我们三种方案这也是我将的在这个时代在ai能够协助我们完成大部分事情的情况下对我们提出的新的考验能够识别和判断ai给的东西是否合理是否能够有更好的方案这不是单单代码能力要求是对业务理解代码能力架构能力的综合考验。ai确实能够帮我们写代码但是现阶段做最终决策的依然是人人的决策能力决定了最终结果的上限。那么作为一个水平不高的人我的选择定然是第一种为什么因为我就见过第一种当然我鼓励我的朋友们去三种都实现毕竟这样才能真正对比出不同方案的优劣而且在这个环境下给了我们试错的资本毕竟不用自己写。但是在完成本章内容后我也会为大家完成这项工作但是纸上得来终觉浅。那么我们后续再见