用户角色菜单(Action)API权限管理方案预研
方案一：前端写死路由权限，跟进不同用户类型判断显示菜单/Action。
缺点：权限固化，不利于扩展，等等……
方案二：动态配置用户-角色-菜单（RBAC），根据配置生成动态路由，显示菜单/Action。
缺点：后端API不能智能识别当前用户是否有访问权限，非法用户可以绕过前端页面直接攻击后端API。
方案三：RBAC+后端自定义注解拦截非法请求。
缺点：后端API授权不够灵活，且不能根据实情动态变化。
想来想去，根据现有的这几种权限管理方案，加上自己的一些臆想，凑出来一个不太完善的权限管理方案，下面详细介绍一下。
2. 总体架构
方案总体借鉴RBAC模式，包含User-Role-Permission-Navigation/Action基本功能，在RBAC的基础上做了扩展，
Navigation/Action会和后端API进行关联，形成一对多的关系，当用户授权Navigation/Action时，就会间接的
对后端API进行授权，最后会生成两组权限信息菜单权限和API权限。
API权限包含三部分：
- Common API（只要是合法用户就能访问的API，如一些查询功能）、
- User API（授权访问的API，由用户授权菜单权限时简介授权的API）
- 服务间调用API（在微服务架构下，服务间通信被视为已经授权动作，所以不做拦截）
这样既满足了菜单动态授权的功能，又同时涵盖了后端API的管理。
3. 实现
系统实现仁者见仁，我介绍一下我的实现方式：
7. 小结
这种方案包括了菜单/Action权限管理和API权限管理，基于API的管理，防止了用户绕过前端项目直接攻击后端接口的行为。
以上是 用户角色菜单(Action)API权限管理方案预研 的全部内容， 来源链接： utcz.com/z/515325.html
