用户权限管理模块设计

在所有web，app，后台管理系统等，都会有一个用户权限管理模块。一个用户权限管理系统，主要包括三个元素：账号、角色、权限。

用户权限管理模块的设计思路：一个用户可以绑定多个角色，一个角色有多个权限，一个权限对应一个权限信息。如图所示：

用户权限一般涉及四张表

• tb_user（用户表）
• tb_role（角色表）
• tb_role_privilege（角色权限关联表）
• tb_catalog（权限信息表）

先看看四张表具有哪些字段吧（这里列出的是核心字段，真正应用时根据自己需要添加额外的字段即刻）

用户表

• 保存用户的账号，密码，电话，是否可用，登录时间，角色id等。其中和用户权限相关的是角色id。

    CREATE TABLE `tb_user` (
      `id` int(10) NOT NULL AUTO_INCREMENT COMMENT 'ID',
      `username` varchar(100) NOT NULL COMMENT '账号',
      `password` varchar(32) DEFAULT NULL COMMENT '密码',
      `user_phone` varchar(20) DEFAULT NULL COMMENT '电话',
      `is_available` tinyint(1) DEFAULT '1' COMMENT '是否可用',
      `login_time` datetime DEFAULT NULL COMMENT '登录时间',
      `role_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '角色id',
      PRIMARY KEY (`id`),
      UNIQUE KEY `username` (`username`)
    ) ENGINE=InnoDB COMMENT='用户表'
  

角色表

• 每个角色的信息。（在添加角色时会新增一条记录入库）

    CREATE TABLE `tb_role` (
      `id` int(10) NOT NULL AUTO_INCREMENT COMMENT 'ID',
      `role_name` varchar(50) DEFAULT NULL COMMENT '角色名称',
      `is_available` tinyint(1) DEFAULT '1' COMMENT '是否可用',
      `add_time` datetime DEFAULT NULL COMMENT '添加时间',
      PRIMARY KEY (`id`),
      UNIQUE KEY `role_code` (`role_code`)
    ) ENGINE=InnoDB COMMENT='角色表'
  

角色权限关联表

• 把角色和权限关联起来，用户拥有角色id，相当于拥有这个角色id对应所有的权限。

    CREATE TABLE `tb_role_privilege` (
      `cat_id` int(10) DEFAULT NULL COMMENT '菜单选项ID',
      `role_id` int(10) DEFAULT NULL COMMENT '角色ID',
      KEY `role_id` (`role_id`),
      CONSTRAINT `tb_role_privilege_ibfk_1` FOREIGN KEY (`role_id`) REFERENCES `tb_role` (`id`) ON DELETE CASCADE ON UPDATE NO ACTION
    ) ENGINE=InnoDB COMMENT='角色权限关联表'
  

角色权限关联表和角色表具有联级删除约束，主要是方便角色删除了，对应的角色权限也从权限表删除。

权限信息表

• 权限信息表其实就是把整个系统的各个模块的权限描述，是整个系统的选项化。

    CREATE TABLE `tb_catalog` (
      `id` int(10) NOT NULL AUTO_INCREMENT COMMENT 'ID',
      `cat_name` varchar(50) DEFAULT NULL COMMENT '名称',
      `cat_code` varchar(100) DEFAULT NULL COMMENT '权限码 用于搜索索引',
      `pid` int(10) DEFAULT '0' COMMENT '父ID',
      `avoid_check` tinyint(1) DEFAULT '0' COMMENT '1.不需要检查，0需要检查',
      PRIMARY KEY (`id`),
      UNIQUE KEY `cat_code` (`cat_code`),
      KEY `pid` (`pid`)
    ) ENGINE=InnoDB COMMENT='权限信息表'
  

为什么要分为四个表？

解耦

主要是为了拓展性强，维护性高；为了整个权限控制管理模块解耦。

复用性

添加用户和添加角色时是没有耦合在一起的，角色和权限是没有耦合在一起的。比如，在添加用户时直接选择一种角色即刻； 在添加权限时，不用考虑角色是啥，在创建角色时直接选择想要的权限进行绑定即刻。提高了各个模块的复用性。

实现要点。

1、权限接口：

• Add（增加一条权限（比如app的评论功能））
• Delete（删除一条权限）
• Update（更新一条权限）
• List（获取所有的权限）
• GetRoleTree（根据请求的表单角色id获取对应所有的权限）

2、角色接口：

• Add（增加一个角色（比如管理员，开发者））
• Delete（删除角色）
• Update（更新角色，信息或者权限）
• List（获取所有的角色）
• AssignPrivilege（分配角色权限。就是把角色和所有分配的权限id绑定入库[tb_role_privilege]）

3、用户接口：

• Add（增加一个用户。此时会绑定角色，前端提供选择角色，并通过表单和用户信息一起传到后台）
• Delete（删除用户）
• Update（更新用户）
• List（获取所有的用户）
• Login（登录。判断是否有此用户？密码是否正确？校验角色是否能登录？把一些重要信息存session，方便后面的接口请求校验权限）
• Logout（退出。删除session信息）

4、登录后的操作接口：

• 中间件拦截请求，做一些校验逻辑
• 通过session拿到此用户的信息，判断是否已登录
• 校验用户的权限是否有权限操作此次请求的模块功能。（通过session的roleid获取对应的权限和此次请求的页面url或访问路径【权限信息表的cat_code】）

• Previous
  docker
• Next
  protobuf