一般的系统在权限设计上，都会分为角色、权限（RDBC），复杂一点的可能会有用户组、组织之类的概念。

用户的权限是写死的，对应于后台的接口或者资源，是没办法改变的，一般不对用户开放修改权限。

管理员用户可以通过给角色分配权限的方式，来实现访问控制。

所以当我们写过滤器，或者用一些安全框架时（比如Shiro，Spring Security），也需要将可变的“角色”，转化为不可变的“权限”，注入到框架中。

具体的可以看我之前写的一篇（Spring Security整合jwt完整版）：https://blog.csdn.net/qq_37855749/article/details/111300906

注入当前用户的权限后，就需要进行访问控制了。

常见的做法有

1、路径比对

之前有个项目用过一次，定义一个过滤器，添加到security的过滤链中，在这个过滤器中做这么一件事：

分析当前访问路径所需要的权限，检查当前用户是否具有该权限，做一个对比，根据对比结果来决定当前用户是否可以访问该资源。

这种做法的好处是代码的入侵性不高，不需要再每个接口上加注解。但相对来说，显得不那么直观，可读性比较差，所以这次换个方法。

2、使用注解的方式

SpringSecurity使用注解来控制访问时，需要提前开启这个功能。

在配置类上加上注解

@Configuration @EnableWebSecurity @EnableGlobalMethodSecurity(prePostEnabled = true) public class SecurityConfig extends WebSecurityConfigurerAdapter {

在接口中如此使用

    /**      * 条件查询      */     @PreAuthorize("hasAuthority('IMPORT:SELECT')")     @ApiOperation(value = "查询")     @GetMapping("/list")     public R> list(TaskDto taskDto){         //测试阶段，随机生成任务         Random random = new Random();          //todo         int i = random.nextInt(4);         if(i == 2) {             metroServerAdapterService.reloadShelveTask();         }         Page list = taskService.list(taskDto);         return R.ok(list);     }

hasAuthority可以替换成hasRole，虽然可以达到相同的目的，但是在使用的方法上还是有些不同的。

hasRole要求内容必须以"ROLE_"开头，也是官方推荐的命名方式，否则没有效果。但是hasAuthority没有限制，数据库中怎样写的，代码里就怎么写。

同样的功能的注解为什么要有两个名字呢。或许这么做可能在语义上比较清晰明确一点，将角色与权限这两个概念稍加区分。

仔细想一下，确实有些小型的系统或许压根就不需要权限，只有给用户分配角色，没有给角色分配权限这一过程。这样的话，角色也是不可变的，就可以根据角色来做访问控制了。

但考虑通用性，个人觉得用hasAuthority就可以了。