用户权限设计
需实现功能如下三点
一 前端:
1、用户登陆展示对应的菜单栏和路由
2、进入界面,根据权限限制分别展示和隐藏按钮 例如:编辑、新增、搜索等
二 后端:
1、访问接口时,是否有权限访问.
2、接口传入的参数数据,例如门店、商品、公司ID等,校验用户是否拥这些数据的权限
3、同一个接口因为不同的用户权限,可能执行过程和结果不一致.
三 权限维护
1、用户权限的crud
2、针对模块设置用户权限
2.1 针对每个模块,可以把单个模块交给某一用户管理,
该用户再给其他用户维护可配置权限(为啥说是"可配置",
因为商品模块交给某一用户,那该用户给别人配置权限时,
总不能配置运营管理模块的权限吧,只能配置当前拥有模块的权限点)
表设计如下:
为了使整体设计比较简洁,会省去id、状态、is_delete、修改新增用户、
修改新增时间等一系列重复、不重要的字段
domain //场景模块 例如:商品模块、运营模块、门店模块
code //编号
name //名称
user 用户
code //编号
name //名称
is_admin //是否时管理员
rule 角色
code
name
action 功能 //接口api or 路由信息
code
name
category // 1api 2ui
parent_code //父级code
action //拥有什么行为 类型数组 例如:crud
group 分组
code
name
group_role 分组里有哪些角色
group_code
role_code
rule_action 角色拥有哪些功能的权限
rule_code
action_code
user_relevance 用户拥有哪些权限
user_code
relevance_code
category // 1、domain 2、rule 3、action 4、group
resource //拥有的数据权限 数组 例如["STORE:1","STORE:2","PRODUCT:2"] category为2的时候才会有
domain_relevance 模块可以配置哪些权限 例如 角色、功能
domain_code
relevance_code
category // 1、rule 2、action
is_admin //是否时管理员
extra //额外能配置的信息 类型数组 例如["STORE","PRODUCT"] 可以添加门店和商品权限 比如只有某个店铺某个商品的权限
一 前端:
1、用户登陆展示对应的菜单栏和路由
1.1 通过login,会直接返回关于用户的菜单、路由信息
1.2 通过user_id 到 user_relevance表里查user对应有哪些模块. category为1
1.3 通过user_id 到 user_relevance表里查user对应有哪些action. category为3
获取出来的action,做一下category为2的过滤就是路由信息了.
查出来的模块,前端就可以直接显示,例如商品、运营、报表等.
路由则是模块下子级或者是单独的url,返回才有权限显示和访问,否则无权显示访问.
2、进入界面,根据权限限制分别展示和隐藏按钮 例如:编辑、新增、搜索等
2.1 通过user_id 到 user_relevance表里查user对应有哪些action. category为3
获取出来的action,做一下category为2的过滤就是路由信息了.
每个子菜单和url对应的就是一个路由,该路由可以通过action字段来获取对应有什么功能.
例如action有["get","add"],那就拥有查询和新增的权限.
二 后端:
1、访问接口时,是否有权限访问.
1.1 user_id 到 user_relevance表里查user对应有哪些action. category为3
获取出来的action,做一下category为1的过滤就是api信息了
整个操作可以在访问接口前的拦截器里实现,把user_id和接口信息丢给权限服务.
权限服务来校验是否有权限,通过以上获取出来的api信息就能和接口进行匹配校验.
2、接口传入的参数数据,例如门店、商品、公司ID等,校验用户是否拥这些数据的权限
通过user_id 到 user_relevance表里查user对应有哪些rule. category为2
通过resource字段 ["STORE:1","STORE:2","PRODUCT:2"],就能知道自己拥有哪些门店、商品的信息
上面这个配置就是拥有门店ID为1和2、商品ID为2的信息
3、同一个接口因为不同的用户权限,可能执行过程和结果不一致.
和前端展示和隐藏按钮步骤几乎一样
user_id 到 user_relevance表里查user对应有哪些action. category为3
获取出来的action,做一下category为1的过滤就是api信息了
获取action字段["exec_calculation"],有exec_calculation接口就会执行计算逻辑.
没有就不会执行这块逻辑.
三 角色和分组
以上写的所有方式其实都不是通过角色和分组来获取权限,
而是获取和用户有直接绑定关系的.
为了显得不那么复杂,所以角色和分组单独抽出来做个说明就好.
1.分组:如果需要把每个详细的权限点都配置给用户,那这个步骤是非常复杂的.
所以需要使用分组,把一些相同的权限点合起来,在配置给用户.
2.角色:其实和分组类似,只不过一般角色会直接归属于某个模块下,一般都是某个模块权限的集合.
会比分组更细一点更精确一点.
3.如果需要通过用户绑定的角色和分组来获取权限(api,ui等等).
直接通过user_id获取出rule和group,在通过rule_action表来获取权限即可.
四 权限维护
1、用户权限的crud
新增用户权限可以使用excel表格批量导入
关于修改和删除需要使用后台来变更
2、针对模块设置用户权限
需求:
针对每个模块,可以把单个模块交给某一用户管理,
该用户再给其他用户维护可配置权限(为啥说是"可配置",
因为商品模块交给某一用户,那该用户给别人配置权限时,
总不能配置运营管理模块的权限吧,只能配置当前拥有模块的权限点)
实现思路:
1.user_id到 user_relevance表里查user对应有哪些rule和admain(场景)
2.admain_id到 domain_relevance表里查出场景下能配置什么角色,
哪些角色是admin权限(is_admin)
3.如果自己有该模块下admin权限(角色里的admin),则可以使用该模块的
权限功能去配置其他用户.
4.domain_id到 domain_relevance表里查对应模块下能配置哪些权限(角色、api、ui)