权限系统设计

权限设计

为什么要有权限设计？

对于一个系统，有多个模块，在需要给不同的用户分配不同的模块权限的场景下，就需要进行权限设计，按需给用户划分对应的权限。比如一个企业系统有用户管理模块、财务管理模块、库存管理模块……对于财务人员来说，只需要财务管理模块的相应权限，不应该分配其他模块的权限；而对于库存人员来说，只需要库存管理模块的权限；对于负责人来说，可能需要所有的模块权限。

权限设计的思路

最开始，用户比较少，就可以用最直观的方式，一个用户需要什么功能，就给他分配功能的权限。

但是随着企业人数逐渐变多，需要分配权限的用户越来越多，刚开始 10 个用户的时候可以手动分配，但是 1000 个用户再手动分配就会变得繁琐低效。

通过对功能分配的观察，有很多用户会分配相同或相似的权限，比如对负责人来说，所有的功能权限都要勾选，每次全都勾选十分复杂，因此可以把这些功能打包起来，成为一个“功能集”。因此可以定义一个“角色”拥有一组功能，就将用户和功能完成了解耦，只需要给用户分配一个角色，便拥有了这个角色对应的所有功能。

如何进行权限设计？

权限设计分为功能权限和数据权限

功能权限：用户登录系统后能看到什么模块，能看到哪些页面
数据权限：用户在某个模块里能看到哪些数据

下面以实际项目为例，介绍项目中如何进行权限设计。

背景信息

项目背景为建设文旅产品，以较为有名的“一机游云南”为例，我们要建设一个“一机游云南”的产品，这个产品包含后台管理系统和小程序，可以在后台编辑活动、咨询、公告等模块，具体的模块下既可以编辑云南省的相关信息，也可以编辑下属景区的信息。如可以编辑云南省的公告信息，也可以编辑下属丽江景区的公告信息。

由于模块众多，且景区众多，让一个管理员来管理工作量显然巨大，因此可以给不同景区和不同模块各自分配相应的管理员来管理。比如可以分配一个管理员拥有丽江、大理的公告模块和活动模块，也可以分配另一个管理员拥有玉龙雪山的咨询、景区信息模块。如果一个管理员没有被分配任何一个景区的公告模块权限，那他就无法看到公告模块，如果只分配了丽江的公告模块权限，那么在公告模块下也只能看到和编辑丽江的信息。

权限系统示意图

采用 RBAC 的思想，用户->角色→权限相分离，用户可以配置多个角色，权限为所有角色的合集

页面设计

由于页面设计相对固定，没有频繁变更功能模块的需求，因此通过配置文件的方式实现。

module:
  # 有二级页面
  - tag: "page_management" # module tag 必须全局唯一
  # saas、私有化-全域和私有化景区文旅通都显示
    category:
      - 0
      - 1
      - 2
    name: "页面管理"
    sub:
      - tag: "page_content"
        name: "页面内容管理"
        access:
        - tag: "info"
          name: "查看"
          url:
            - "/tourism_inner/v1/management/info"
            - "/tourism_inner/v1/management/list"
        - tag: "edit"
          name: "编辑"
          url:
            - "/tourism_inner/v1/management/edit"
      - tag: "page_layout"
        name: "页面布局管理"
        access:
        - tag: "info"
          name: "查看"
          url:
            - "/tourism_inner/v1/layout/add"
   # 没有二级页面
  - tag: "scenic_management"
    name: "景区管理"
    # 只有景区文旅通显示
    category:
      - 1
    access:
      - tag: "edit"
        name: "编辑"
        url:
          - "/tourism_inner/v1/scenic/update"

角色设计

设计角色表如下：

CREATE TABLE `role` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增id',
  `product_id` bigint(20) NOT NULL COMMENT '产品id',
  `name` varchar(20) NOT NULL COMMENT '角色名',
  `category` tinyint(1) NOT NULL COMMENT '类型: 1全域角色 2景区角色',
  `content` text NOT NULL COMMENT '角色内容',
  `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '状态: 1有效 0无效',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  KEY `idx_product` (`product_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='角色表';

content：为该角色关联的模块信息，举例如下：

[
    {
        "tag":"page_content",
        "access":["info", "edit"]
    },
    {
        "tag":"page_layout",
        "access":["edit"]
    },
    {
        "tag": "scenic_management",
        "access": ["edit"]
    }
]

该角色有 页面管理→页面内容管理 的查看和编辑权限，页面管理→页面布局管理 的查看权限。

用户角色关联设计

用户角色授权表为：

CREATE TABLE `authorization` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `authorizer_id` bigint(20) NOT NULL COMMENT '用户id',
  `role_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '角色id',
  `domain_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '全域id',
  `scenic_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '授权景区id',
  `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '状态：1有效 0无效',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `unique_authorizer` (`authorizer_id`,`domain_id`,`scenic_id`),
  KEY `idx_domain` (`domain_id`),
  KEY `idx_scenic` (`scenic_id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8mb4 COMMENT='用户-角色授权表';