假期前几天，给大家简单分享了橙单框架中的操作日志的体系，包括如何把从前端，到elk，再到skywalking等，如何完整的串联，如何使用定位线上问题，同时还介绍了JWT token部分，我们是如何实现用户身份验证的。今天分享一下我们的权限部分。
橙单的权限部分，比较完整且灵活，但是如果不了解他们的作用，往往会觉得相对复杂，特别是权限字部分，其实这个是和shiro中的权限字是对等的。
今天不讲代码，只是从需求视角介绍一下，为啥要这样设计，
这五类数据，分别存储在独立的数据表中，同时自顶而下，他们之间都有一张多对多的关联表。这样的设计结构，就可以保证权限部分的足够灵活，可以覆盖绝大多数的通用场景了。
用户 -> 分配角色 -> 角色 -> 分配菜单 -> 菜单，从而保证了，用户登录之后，有哪些菜单可见。
这个是最最简单的一种方式，只是从菜单可见性方面，实现了权限部分。如果仅仅如此，那么权限体系，很不安全，也基本不可用。postman的请求很轻松就实现了越权访问。
用户 -> 分配角色 -> 角色 -> 分配菜单 -> 菜单 -> 分配权限字 -> 权限字，从而保证了，用户登录之后，有哪些前端组件可见。
这一点非常非常重要，首先前端精确到了组件，而且菜单，这个粒度更加细致了，权限包括组件和Tab标签(标签内的所有组件)。我们试想一下，从管理员操作视角看，管理员在分配权限的时候，其实就是将菜单分配给角色，根本不会考虑到菜单和权限字的关联关系，这些关联关系，一般是开发实施团队，提供技术服务的。毕竟甲方的管理员，无需关心权限字，以及更为底层的权限资源url。
否则的话，如果没有权限字，就得让url和菜单直接绑定，那么应该也可以，这样系统管理员在给角色添加权限的时候，可能就会面对更多的ui组件，如果组件变化了，角色权限也得变化，这显然是不合理的。
因为菜单和权限字是多对多的关系，所以一个菜单可以关联多个权限字，这样系统管理员仅仅配置角色 -> 菜单的关系即可。
这样相对是比较直观的
另外就是从权限字视角来看了，同一个弹框可能是同一个权限字，他可能是不同的表单按照触发的，这样权限字和菜单的多对多关键，就可以保证权限字被多个菜单复用，而无需为同一个弹框，不同的触发入口，创建多个权限字了。
最后是权限资源，也就是url，这个是后台进行权限验证的关键。
用户 -> 分配角色 -> 角色 -> 分配菜单 -> 菜单 -> 分配权限字 -> 权限字 -> 绑定权限资源 -> 权限资源(url)，从而保证了，用户登录之后，后台可以控制，当前用户有哪些url接口是可以访问的。这些都连同白名单url，一起缓存到redis中。
权限是分树形模块的，这样便于管理吧，每个controller，是一个缺省的模块，从该ui的布局，可以看到，这些数据的维护，都是非常低频的，一般都是系统升级，有实施人员操作的
最后就是给权限字分配url权限资源了
这个就比较好理解了
单体的后台权限验证代码，在拦截器中统一处理，微服务再网关过滤器中统一处理
从权限资源视角看，我新增一个接口，直接挂接到某个权限字上，这样有该权限字权限的用户，自然就可以访问这个接口了，否则的话，新增的接口，除了管理员就没人能够访问了。
从用户 -> 角色 -> 菜单 -> 权限字 -> 权限字，中间经历多个节点，为了便于线上权限问题的排查，我们还提供了一组查询接口和ui，我们后面会继续分享。
