管理系统之权限的设计和实现

时间 2019-11-08

标签管理系统权限设计实现繁體版

原文原文链接

本文主要想对前端权限管理功能实现作一个分享，因此并不会对后台管理的框架结构作太详细介绍，若是有朋友对其余有兴趣能够留言。前端

基本设计和分析

前端 vue + elementui
服务端: node + mysql + nginx

主要功能

打开思否页面，根据页面的功能点，设计出相关的数据表，和管理系统须要的相关页面。
计划后台管理须要完成的功能：vue

权限管理（菜单权限到数据权限） -- 已完成
工做流（问答和文章在某个条件内，提交须要走流程）-- 未完成
socket （对用户点赞，评论，系统通知等消息进行实时推送）-- 未完成
文件管理（将页面须要用到的文件上传管理，其余页面都统一访问文件库资源）-- 已完成
基本业务（业务页面）-- 部分完成

模块相关介绍

模块	功能	页面编码	描述
登陆	登陆	login	菜单中不显示
401	401	401	角色无访问权限时进入这个页面
404	404	404	访问菜单不存在时进入这个页面
首页	首页	home
运维中心		opsCenter
-	问答管理	questionMan
-	专栏管理	blogMan
-	文章管理	articleMan
-	讲堂管理	liveMan
-	活动管理	activityMan
-	广告位	advertising
工做流		workflow
-	流程设计	processDesign
-	业务管理	businessMan
-	已办事项	finishedItems
-	未办事项	unfinishedItems
文件库		library
-	图片管理	imgMan
-	文件管理	fileMan
论坛配置		bbsConfig
-	轮播	carousel
-	技术频道	techSquare
-	通知	notices
-	标签类型管理	tagTypeMan
-	标签管理	tagMan
系统管理		sysMan
-	用户管理	userMan
-	角色管理	roleMan
-	菜单管理	menuMan
-	区域管理	areaMan
-	图表配置	chartConfig
-	系统日志	log

代码结构

├── admin                      // 打包产出文件
├── node_module                // npm加载所需的项目依赖模块
├── public                     // 静态入口
├── src                        // 源代码
│   ├── api                    // 全部请求
│   ├── assets                 // 主题 字体 图片等静态资源
│   ├── common                 // 全局公用配置
│   │   ├── config             // 配置全局路由权限和错误捕获
│   │   ├── mixin              // 一些vue公用的mixin
│   │   ├── js                 // 编写公有的方法
│   │   └── style              // 编写公有的样式
│   ├── components             // 全局公用组件
│   ├── directive              // 自定义指令
│   ├── router                 // 路由
│   ├── store                  // 全局 store管理
│   ├── views                  // view
│   ├── App.vue                // 入口页面
│   └── main.js                // 入口 加载组件 初始化等
├── static                     // 第三方不打包资源
├── .babelrc                   // babel-loader 配置
├── eslintrc.js                // eslint 配置项
├── .gitignore                 // git 忽略项
├── vue.config.js              // vue-cli@3.0+ 配置文件
└── package.json               // package.json

权限设计

进入正文，关于权限设计，围绕的是前端页面，可是会将前端和后端的逻辑都讲出来。node

用户管理

建立

前端页面

看图中圈起来的地方，前端看到的逻辑是这样的：mysql

当前用户为admin
树用右键操做是admin建立的用户
树用右键操做建立的用户admin能够管理

就是建立了一个用户，这个用户建立的用户以及建立用户建立的用户，均可以被当前建立者管理。nginx

接口逻辑

查询到数据库中全部的用户ID
经过用户ID和建立人ID的关系，经过创建树状数据，获得当前用户建立的用户树
递归从用户树中获得全部属于当前用户子集的用户ID
select * from table where id in (子集用户id)

经过这个逻辑，能够获得全部当前用户建立的子集，可是第一步有很大的问题，一旦用户数量巨大，这样查询会很慢。母目前只是为了功能实现，暂未考虑到性能方面，若是有好的方法，但愿指点。git

删除

前端页面

删除用户，调用接口判断用户是否有子集，存在->3，不存在->2
不存在直接删除
存在须要先将当前建立的用户转移给其余用户（其余用户不可为他的子集）
将用户转移成功,则此时子集为空 ->2

接口逻辑

查询到数据库中是否存在建立人ID为当前要删除的用户ID
存在则没法删除当前用户
前端调用户转移接口，将当前用户建立的用户转移给其余人后，此时可删除该用户

菜单管理

菜单设计的时候分为三个类型，管理平台，论坛，移动端，可是不必定会写完，感受一我的写好累呀~~~~
经过菜单又分还有默认布局组件和页面组件的区分，布局组件为layout，页面组件则为他的子路由，经过嵌套的形式，组成一个完整的页面。
github

页面

目前页面上都是经过右键点击树组件，进入操做，如图所示，能够对菜单进行增删改查操做。sql

菜单字段的定义和相关用处
字段定义是这样的：
看到图中有这些字段，对主要字段说明：

菜单编码（对应前端页面的文件名，好比userMan, 渲染时就会找到 */userMan/index去resolve）
菜单组件 (指的是layout等，后面若是须要作多布局，经过这个设置页面便可有不一样布局)

-- ----------------------------
-- bbs_menu
-- ----------------------------
DROP TABLE IF EXISTS `bbs_menu`;
CREATE TABLE `bbs_menu` (
  `id` INT(11) NOT NULL AUTO_INCREMENT,
  `pid` INT(11) DEFAULT '0',
  `type` tinyint(4) NOT NULL DEFAULT '1' COMMENT '菜单类型: 1. 管理平台菜单 2. BBS菜单 3. 移动端菜单',
  `code` VARCHAR(48) NOT NULL COMMENT '菜单编码',
  `name` VARCHAR(48) NOT NULL COMMENT '菜单名称',
  `component` tinyint(4) NOT NULL COMMENT '对应组件: -1. 根节点 1. 页面组件 2.默认布局 3456...扩展布局',
  `icon` VARCHAR(128) DEFAULT NULL COMMENT '菜单图标',
  `alias` VARCHAR(128) DEFAULT NULL COMMENT '别名',
  `redirect` VARCHAR(128) DEFAULT NULL COMMENT '重定向路径: 配置菜单编码或URL',
  `sort` INT(11) NOT NULL,
  `desc` VARCHAR(128) DEFAULT NULL,
  `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态: 0：停用，1：启用(默认为1)',
  `create_user` INT(11) DEFAULT NULL,
  `create_time` datetime DEFAULT NULL,
  `update_user` INT(11) DEFAULT NULL,
  `update_time` datetime DEFAULT NULL,
  `delete_user` INT(11) DEFAULT NULL,
  `delete_time` datetime DEFAULT NULL,
  `flag` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态: 0：删除，1：可用(默认为1)',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='菜单表';

id: '', // *惟一ID
    pid: '', // *父ID
    type: '', // *菜单类型
    code: '', // *菜单编码
    name: '', // *菜单名称
    component: '', // *菜单组件
    icon: '', // 菜单图标
    redirect: '', // 重定向路径
    sort: '', // *排序
    desc: '', // 描述
    status: 1 // *状态: 0：停用，1：启用(默认为1)'

有什么用处呢和好处呢，就我的而言，就是以为把路由表放在数据库，让项目更易于维护，在页面中经过一个匹配逻辑，能够将全部字段组装成为可使用的路由表:vue-cli

// 获得页面路径
function getPath (arr, child, code) {
  const pItem = arr.find(item => child.pid === item.id)
  // 当前元素还存在父节点, 且父节点不为根节点
  if (arr.find(item => pItem.pid === item.id && item.pid > -1)) {
    getPath(arr, pItem, `${pItem.code}/${code}`)
  } else {
    return `${pItem.code}/${code}`
  }
}
// 对基础数据的处理
              item.meta = {}
              item.meta.title = item.name
              item.meta.icon = item.icon
              item.meta.id = item.id
              // 使路由名字具备惟一性
              item.name = item.name + index
              // 设置对应的页面路径
              item.path = '/' + item.code
// 设置页面对应的组件 对应组件: -1. 根节点 1. 页面组件 2.默认布局 3456...扩展布局
              switch (item.component) {
                case -1:
                  console.log('根节点，已通过滤掉了')
                  break
                case 1:
                  item.component = resolve => require([`@/views/${getPath(menu, item, item.code)}/index`], resolve)
                  break
                case 2:
                  item.component = Layout
                  break
                default:
                  item.component = resolve => require(['@/views/errorPage/401'], resolve)
                  break
              }

经过这种方式，在设置页面权限的时候，只须要接口设置当前角色对应的菜单，用户查询的时候能获取到的就是当前分配给他的权限，将这个权限组装成路由表，便可。数据库