因为好久没写了，所以今天补上。 本篇没有实际的代码。 主要是设计思路。
关于JWT :在我开发的系统中，用户Token都是有意义的，它携带一些数据，但经常用于userId
个人权限系统使用历史记录：
(Security (不加表，将角色放入Token ) )根据注释进行验证) (一团糟) ) ) ) ) ) ) ) ) )。
使用Spring Security框架在帐户表中编写用户角色ROLE_USER，以实现用户详细信息服务的方式封装和返回用户详细信息，并向接口添加注释
好处很简单，但权限写在逻辑里。 必须发布版本才能更改权限。 在小系统中，可以这样请求验证地址前缀(按模块)
在儒家的冬天，按角色划分接口地址类似于划分微服务模块，只是为了验证权限而进行的划分。 另外，老实说，也很难升级。 RBAC模型用户表、角色表、菜单、接口表和关系表
活着看。 但是，后来的很多想法都是基于这个表结构。
RBAC数据库
AccessDecisionManager界面实现
filterinvocationfilterinvocation=(过滤器调用) object； setstring URIs=smsaccountrolemapper.URIs ((string ) authentication.getPrincipal ) )； if (URIs.contains (filter invocation.getrequest URL () ) { return； } else { log.info ('当前请求路径：[{}]用户权限为：[{}] '，filterInvocation.getRequestUrl )，uris )； throw new访问权限deniedexception ('权限不足)； }到此为止实现了界面权限的动态配置，同时到此为止是没有营养的无厘头，接下来会更经典。
使用Redis JWT
Redis用于存储JWT，JWT用于存储用户id
实现authorizationservertokenservices的createAccessToken、refreshAccessToken方法不需要实现TokenStore，直接写在MyTokenService中即可
技巧:以下所有存储都将Redis的有效期设置尽可能短于实际有效期一个小时，以防止Redis验证通过且Token分析失败
前缀含义UNAME_TO_ACCESS用户访问令牌，主要是在用户块冻结时删除Token，单设备登录限制access _ to _ useraccesstokenuserid， 这里是Token真实性access _ to _ refreshaccessTokenrefreshtoken的验证、与帐户冻结时的当前帐户有关的token信息的删除， 仅用于更新refresh _ to _ accessrefreshtokenaccesstoken，并在使用完毕后删除旧的accessTokenREFRESHrefreshToken信息，然后使用令牌http://www.Sina.cccona
1、开放性接口直接太过
2、需要登录的由Redis负责，检查是否是真正有效的Token
3、根据需要权限检查的数据库RBAC关系进行查询检查。
微服务
其实微服务和前面的一样，认证中心发布Token，网关进行认证，验证所有逻辑是否基本一致
前端按钮验证
这里请安利开源项目。 若依，给了我很多启发。
上表结构接口表包含一个名为前端验证密钥的字段。 具体来说，后端在用户登录后将Set集合返回到前端，前端将标签封装在组件中。 如v-if所示，参数是此按钮的认证密钥，如果在Set集合中，则显示；否则不显示按钮。
下图是经过非常仔细考虑的验证逻辑，其中一个按钮可能支持多个接口。
建议：建议尽量匹配后端接口名称。 因为后端接口不能提供两个相同的接口(请尽量使用后期映射)。
前端页面验证
页面比按钮复杂的原因是，后端的一个接口在多个页面上调用，而一个页面调用后端的多个接口，因此后端提供路由配置并不那么有用。 因此，前端知道当前页面调用的接口，也知道哪些接口具有权限验证。 另外，考虑到前端的某些数据今天显示在这里，明天可能会发生位置变化，我们考虑将页面级路由传递给前端进行自我验证。 具体逻辑如下。
1、当前页面存在开放界面，像查询一样直接展示
2、当前页面的所有接口都需要权限时，验证后端返回的Set集合中当前页面的接口和key是否交叉，显示时不隐藏时进行验证
DBAC模式儒教之冬：在同一个界面上，每个人访问看到的数据都不一样。 所谓这个区别，并不是看的自己的数据不同，而是在同一页上只能看到自己的东西。 老师能看班级，校长能看全校。
数据权限必须根据系统的实际使用进行设计。 虽然有几种通用的设计方案，但是如果不设计直接拿来使用，一定会面临性能问题。
统一权限
如果一个人对系统的操作级别固定，且只有在角色发生变化时才发生变化，则可以使用“是”实现方式、MyBatis拦截器方式来确定用户权限级别并连接SQL后缀，而“是”的简单实现方式因为他的部门作用是基本实现。 权限分割
一个用户对系统中不同接口的访问权限不同，不仅仅是部门问题。 (例如，如果一个部门的部长犯了错误，公司让他回家反省，他还是部长，但他登录系统后可能只能看到自己的数据。 ）
思路：将前端验证思路转移到后端，在MyBatis界面中添加注释，在拦截器中判断当前用户对当前SQL的权限级别是什么，并将不同的SQL后缀与搜索语句联系起来。
用户，如果知道mapper界面，就可以看到对应的SQL后缀是什么，然后动态连接起来。 欢迎留言。 有时间的话请做开源项目大家一起玩。