# 权限认证 --- ### 核心思想 所谓权限认证,认证的核心就是一个账号是否拥有一个权限码
有,就让你通过。没有?那么禁止访问! 再往底了说,就是每个账号都会拥有一个权限码集合,我来校验这个集合中是否包含指定的权限码
例如:当前账号拥有权限码集合:`["user-add", "user-delete", "user-get"]`,这时候我来校验权限 `"user-update"`,则其结果就是:**验证失败,禁止访问**
所以现在问题的核心就是: 1. 如何获取一个账号所拥有的的权限码集合 2. 本次操作需要验证的权限码是哪个 ### 获取当前账号权限码集合 因为每个项目的需求不同,其权限设计也千变万化,因此【获取当前账号权限码集合】这一操作不可能内置到框架中, 所以 Sa-Token 将此操作以接口的方式暴露给你,以方便的你根据自己的业务逻辑进行重写 你需要做的就是新建一个类,实现`StpInterface`接口,例如以下代码: ``` java package com.pj.satoken; import java.util.ArrayList; import java.util.List; import org.springframework.stereotype.Component; import cn.dev33.satoken.stp.StpInterface; /** * 自定义权限验证接口扩展 */ @Component // 保证此类被SpringBoot扫描,完成Sa-Token的自定义权限验证扩展 public class StpInterfaceImpl implements StpInterface { /** * 返回一个账号所拥有的权限码集合 */ @Override public List getPermissionList(Object loginId, String loginType) { // 本list仅做模拟,实际项目中要根据具体业务逻辑来查询权限 List list = new ArrayList(); list.add("101"); list.add("user-add"); list.add("user-delete"); list.add("user-update"); list.add("user-get"); list.add("article-get"); return list; } /** * 返回一个账号所拥有的角色标识集合 (权限与角色可分开校验) */ @Override public List getRoleList(Object loginId, String loginType) { // 本list仅做模拟,实际项目中要根据具体业务逻辑来查询角色 List list = new ArrayList(); list.add("admin"); list.add("super-admin"); return list; } } ``` 可参考代码:[码云:StpInterfaceImpl.java](https://gitee.com/dromara/sa-token/blob/master/sa-token-demo/sa-token-demo-springboot/src/main/java/com/pj/satoken/StpInterfaceImpl.java) ### 权限认证 然后就可以用以下api来鉴权了 ``` java // 当前账号是否含有指定权限, 返回true或false StpUtil.hasPermission("user-update"); // 当前账号是否含有指定权限, 如果验证未通过,则抛出异常: NotPermissionException StpUtil.checkPermission("user-update"); // 当前账号是否含有指定权限 [指定多个,必须全部验证通过] StpUtil.checkPermissionAnd("user-update", "user-delete"); // 当前账号是否含有指定权限 [指定多个,只要其一验证通过即可] StpUtil.checkPermissionOr("user-update", "user-delete"); ``` 扩展:`NotPermissionException` 对象可通过 `getLoginType()` 方法获取具体是哪个 `StpLogic` 抛出的异常 ### 角色认证 在Sa-Token中,角色和权限可以独立验证 ``` java // 当前账号是否含有指定角色标识, 返回true或false StpUtil.hasRole("super-admin"); // 当前账号是否含有指定角色标识, 如果验证未通过,则抛出异常: NotRoleException StpUtil.checkRole("super-admin"); // 当前账号是否含有指定角色标识 [指定多个,必须全部验证通过] StpUtil.checkRoleAnd("super-admin", "shop-admin"); // 当前账号是否含有指定角色标识 [指定多个,只要其一验证通过即可] StpUtil.checkRoleOr("super-admin", "shop-admin"); ``` 扩展:`NotRoleException` 对象可通过 `getLoginType()` 方法获取具体是哪个 `StpLogic` 抛出的异常 ### 拦截全局异常 有同学要问,鉴权失败,抛出异常,然后呢?要把异常显示给用户看吗?**当然不可以!**
你可以创建一个全局异常拦截器,统一返回给前端的格式,参考:[码云:GlobalException.java](https://gitee.com/dromara/sa-token/blob/master/sa-token-demo/sa-token-demo-springboot/src/main/java/com/pj/test/GlobalException.java) ### 权限通配符 Sa-Token允许你根据通配符指定泛权限,例如当一个账号拥有`user*`的权限时,`user-add`、`user-delete`、`user-update`都将匹配通过 ``` java // 当拥有 user* 权限时 StpUtil.hasPermission("user-add"); // true StpUtil.hasPermission("user-update"); // true StpUtil.hasPermission("art-add"); // false // 当拥有 *-delete 权限时 StpUtil.hasPermission("user-add"); // false StpUtil.hasPermission("user-delete"); // true StpUtil.hasPermission("art-delete"); // true // 当拥有 *.js 权限时 StpUtil.hasPermission("index.js"); // true StpUtil.hasPermission("index.css"); // false StpUtil.hasPermission("index.html"); // false ``` 上帝权限:当一个账号拥有 `"*"` 权限时,他可以验证通过任何权限码 (角色认证同理) ### 如何把权限精确搭到按钮级? 权限精确到按钮级的意思就是指:**权限范围可以控制到页面上的每一个按钮是否显示** 思路:如此精确的范围控制只依赖后端已经难以完成,此时需要前端进行一定的逻辑判断 1. 在登录时,把当前账号拥有的所有权限码一次性返回给前端 2. 前端将权限码集合保存在`localStorage`或其它全局状态管理对象中 3. 在需要权限控制的按钮上,使用js进行逻辑判断,例如在`vue`框架中我们可以使用如下写法: ``` js ``` 其中:`arr`是当前用户拥有的权限码数组,`user:delete`是显示按钮需要拥有的权限码,`删除按钮`是用户拥有权限码才可以看到的内容 注意:以上写法只为提供一个参考示例,不同框架有不同写法,开发者可根据项目技术栈灵活封装进行调用 ### 前端有了鉴权后端还需要鉴权吗? **需要!** 前端的鉴权只是一个辅助功能,对于专业人员这些限制都是可以轻松绕过的,为保证服务器安全,无论前端是否进行了权限校验,后端接口都需要对会话请求再次进行权限校验! ### 将权限数据放在缓存里 前面我们讲解了如何通过`StpInterface`接口注入权限数据,框架默认是不提供缓存能力的,如果你想减小数据库的访问压力,则需要将权限数据放到缓存中 参考示例: ``` java /** * 返回一个账号所拥有的权限码集合 */ @Override public List getPermissionList(Object loginId, String loginType) { // 1. 获取这个账号所属角色id long roleId = StpUtil.getSessionByLoginId(loginId).get("Role_Id", () -> { return ...; // 从数据库查询这个账号所属的角色id }); // 2. 获取这个角色id拥有的权限列表 SaSession roleSession = SaSessionCustomUtil.getSessionById("role-" + roleId); List list = roleSession.get("Permission_List", () -> { return ...; // 从数据库查询这个角色id拥有的权限列表 }); // 3. 返回 return list; } ``` 以上仅为代码示例,角色列表步骤同理 ##### 疑问:为什么不直接缓存 `[账号id->权限列表]`的关系,而是 `[账号id -> 角色id -> 权限列表]`? 答:`[账号id->权限列表]`的缓存方式虽然更加直接粗暴,却有一个严重的问题: - 通常我们系统的权限架构是RBAC模型:权限与用户没有直接的关系,而是:用户拥有指定的角色,角色再拥有指定的权限 - 而这种'拥有关系'是动态的,是可以随时修改的,一旦我们修改了它们的对应关系,便要同步修改或清除对应的缓存数据 现在假设如下业务场景:我们系统中有十万个账号属于同一个角色,当我们变动这个角色的权限时,难道我们要同时清除这十万个账号的缓存信息吗? 这显然是一个不合理的操作,同一时间缓存大量清除容易引起Redis的缓存雪崩 而当我们采用 `[账号id -> 角色id -> 权限列表]` 的缓存模型时,则只需要清除或修改 `[角色id -> 权限列表]` 一条缓存即可 一言以蔽之:权限的缓存模型需要跟着权限模型走,角色缓存亦然