用户权限设计

用户权限设计

需实现功能如下三点

一 前端:

 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)