实现思路
 
1.页面展示需要鉴权的所有按钮，需要先鉴权菜单权限的显示与隐藏。
 
2.勾选每个角色或者用户所能看的权限保存在数据库。该权限数据是一个权限字段的数组。
 
3.全局自定义指令（directive）控制按钮权限数据的方法，登入时获取后端传来的按钮权限数组。
 
4.在每个按钮中调用该指令，并传入该操作的权限字段和后端保存的权限字段进行匹配，能匹配则该操作按钮可显示
 
具体代码如下
 
获取登录用户所有权限
 
// 获取权限菜单(存在store下modules下user.js的actions中)
 getMenuTree ({ commit, state }) {
   return new Promise((resolve, reject) => {
     getMenuTree(state.token).then(response => {
       const data = response.result
       if (!data) {
         reject('验证失败，请重新登录')
       }
       // 存菜单结构
       commit('SET_ROLES', data)
       // 重置按钮权限
       btns = []
       const btn = findAllBtn(data)
       // 存所有按钮权限
       commit('SET_BUTTONS', btn)
       resolve(data)
     }).catch(error => {
       reject(error)
     })
   })
 }
// 递归获取按钮list
let btns = []
export function findAllBtn (list) {
 list.forEach(val => {
 // 与后台协商所有菜单资源（resCode)下的type是1表菜单，2为按钮
   if (val.type === '1') {
     if (val.children && val.children.length > 0) {
       findAllBtn(val.children)
     }
   } else {
     btns.push(val.reCode)
   }
 })
}
 
对比菜单权限的方法
 
在store下modules下新建一个permission.js(获取最终动态权限菜单）
/**
* @param  {Array} userRouter 后台返回的用户权限json
* @param  {Array} allRouter  前端配置好的所有动态路由的集合
* @return {Array} realRoutes 过滤后的路由
*/
export function recursionRouter (userRouter = [], allRouter = []) {
 let realRoutes = []
 allRouter.forEach(val => {
   userRouter.forEach(item => {
     if (val.path.includes('/')) {
       if (item.resCode === val.path.split('/')[1]) {
         val.children = recursionRouter(item.children, val.children)
         realRoutes.push(val)
       }
     } else {
       if (item.resCode === val.path) {
         if (item.children && item.children.length > 0) {
           val.children = recursionRouter(item.children, val.children)
         }
         realRoutes.push(val)
       }
     }
   })
 })
 realRoutes.push({ path: '*', redirect: '/404', isShow: true })
 // console.log(222, realRoutes)
 return realRoutes
}
// asyncRouterMap本地配置好的所有动态路由的集合
const actions = {
 generateRoutes ({ commit }, roles) {
   return new Promise(resolve => {
     let accessedRoutes = recursionRouter(roles, [...asyncRouterMap])
     commit('SET_ROUTES', accessedRoutes)
     resolve(accessedRoutes)
   })
 }
}
 
对比菜单权限需要在全局路由守卫中如下操作
 
router.beforeEach(async (to, from, next) => {
 // 确定用户是否已登录
 const hasToken = getToken()
 // 判断是否有token
 if (hasToken) {
   // 运营端登录
   if (to.path === '/login') {
     // 如果已登录，则重定向到主页
     next({ path: '/' })
     NProgress.done()
   } else {
     // 确定用户是否已获得了他的权限角色
     const hasRoles = store.getters.roles && store.getters.roles.length > 0
     if (hasRoles) {
       next()
     } else {
       // 角色必须是对象数组
       const roles = await store.dispatch('user/getMenuTree')
         // 根据角色生成可访问路由映射
         const accessRoutes = await store.dispatch('permission/generateRoutes', roles)
         // 清空静态路由
         resetRouter()
         // 动态添加可访问路由
         router.addRoutes(accessRoutes)
         // hack 方法，以确保addRoutes是完整的
         // 设置replace: true，这样导航就不会留下历史记录
         next({ ...to, replace: true })
     }
   }
 } else {
   // 在免登录白名单，直接进入
   if (whiteList.indexOf(to.path) !== -1) {
     next()
   } else {
     // 没有访问权限的其他页面被重定向到登录页面
     next(`/login?redirect=${to.path}`)
     NProgress.done()
   }
 }
})
 
全局自定义指令
 
// 需要全局注入（即在main.js引入）
import Vue from 'vue'
import store from '@/store'
/**
 * 使用：v-permission="'resCode'"
 *   resCode 按钮资源（即路由path）
 * **/
Vue.directive('permission', {
  inserted (el, vDir) {
    let btnPermission = store.getters.buttons
    if (vDir.value) {
      if (!btnPermission.includes(vDir.value)) {
        el.parentNode.removeChild(el)
      }
    }
  }
})
 
页面中使用
 
<el-button type="primary" @click="roleExport" v-permission="'ent-role-export'">导出</el-button>
 
如图
 
初始
 取消权限后
 
 
 
 
相关文章
 
基于elementUI中table组件二次封装（Vue项目）
 
 
axios二次封装，接口统一存放,满足RESTful风格
 
 
keep-alive不能缓存多层级路由(vue-router)菜单问题解决
 
 
基于ElementUi再次封装基础组件文档

 
 
每天早上七点三十，准时推送干货
 

 
一、介绍
 
在实际的项目开发过程中，菜单权限功能可以说是后端管理系统中必不可少的一个环节，根据业务的复杂度，设计的时候可深可浅，但无论怎么变化，设计的思路基本都是围绕着用户、角色、菜单进行相应的扩展。
 
今天小编就和大家一起来讨论一下，怎么设计一套可以精确到按钮级别的菜单权限功能，废话不多说，直接开撸！
 
二、数据库设计
 
先来看一下，用户、角色、菜单表对应的ER图，如下：
 
 
其中，用户和角色是多对多的关系，角色与菜单也是多对多的关系，用户通过角色来关联到菜单，当然也有的业务系统菜单权限模型，是可以直接通过用户关联到菜单，对菜单权限可以直接控制到用户级别，不过这个都不是问题，这个也可以进行扩展。
 
对于用户、角色表比较简单，下面，我们重点来看看菜单表的设计，如下：
 
 
可以看到，整个菜单表就是一个树型结构，关键字段说明：
 
menu_code：菜单编码，用于后端权限控制
parent_id：菜单父节点ID，方便递归遍历菜单
node_type：节点类型，可以是文件夹、页面或者按钮类型
link_url：页面对应的地址，如果是文件夹或者按钮类型，可以为空
level：菜单树的层次，以便于查询指定层级的菜单
path：树id的路径，主要用于存放从根节点到当前树的父节点的路径，逗号分隔，想要找父节点会特别快
 
为了后面方便开发，我们先创建一个名为menu_auth_db的数据库，初始脚本如下：
 
CREATE DATABASE IF NOT EXISTS menu_auth_db default charset utf8mb4 COLLATE utf8mb4_unicode_ci;

CREATE TABLE menu_auth_db.tb_user (
  id bigint(20) unsigned NOT NULL COMMENT '消息给过来的ID',
  mobile varchar(20) NOT NULL DEFAULT '' COMMENT '手机号',
  name varchar(100) NOT NULL DEFAULT '' COMMENT '姓名',
  password varchar(128) NOT NULL DEFAULT '' COMMENT '密码',
  is_delete tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否删除 1：已删除；0：未删除',
  PRIMARY KEY (id),
  KEY idx_name (name) USING BTREE,
  KEY idx_mobile (mobile) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='用户表';

CREATE TABLE menu_auth_db.tb_user_role (
  id bigint(20) unsigned NOT NULL COMMENT '主键',
  user_id bigint(20) NOT NULL COMMENT '用户ID',
  role_id bigint(20) NOT NULL COMMENT '角色ID',
  PRIMARY KEY (id),
  KEY idx_user_id (user_id) USING BTREE,
  KEY idx_role_id (role_id) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='用户角色表';

CREATE TABLE menu_auth_db.tb_role (
  id bigint(20) unsigned NOT NULL COMMENT '主键',
  code varchar(100) NOT NULL DEFAULT '' COMMENT '编码',
  name varchar(100) NOT NULL DEFAULT '' COMMENT '名称',
  is_delete tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否删除 1：已删除；0：未删除',
  PRIMARY KEY (id),
  KEY idx_code (code) USING BTREE,
  KEY idx_name (name) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='角色表';


CREATE TABLE menu_auth_db.tb_role_menu (
  id bigint(20) unsigned NOT NULL COMMENT '主键',
  role_id bigint(20) NOT NULL COMMENT '角色ID',
  menu_id bigint(20) NOT NULL COMMENT '菜单ID',
  PRIMARY KEY (id),
  KEY idx_role_id (role_id) USING BTREE,
  KEY idx_menu_id (menu_id) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='角色菜单关系表';


CREATE TABLE menu_auth_db.tb_menu (
  id bigint(20) NOT NULL COMMENT '主键',
  name varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '名称',
  menu_code varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '菜单编码',
  parent_id bigint(20) DEFAULT NULL COMMENT '父节点',
  node_type tinyint(4) NOT NULL DEFAULT '1' COMMENT '节点类型，1文件夹，2页面，3按钮',
  icon_url varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '图标地址',
  sort int(11) NOT NULL DEFAULT '1' COMMENT '排序号',
  link_url varchar(500) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '页面对应的地址',
  level int(11) NOT NULL DEFAULT '0' COMMENT '层次',
  path varchar(2500) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '树id的路径 整个层次上的路径id，逗号分隔，想要找父节点特别快',
  is_delete tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否删除 1：已删除；0：未删除',
  PRIMARY KEY (id) USING BTREE,
  KEY idx_parent_id (parent_id) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='菜单表';

 
三、后端开发
 
菜单权限模块的数据库设计，一般5张表就可以搞定，真正有点复杂的地方在于数据的写入和渲染，当然如果老板突然让你来开发一套菜单权限系统，我们也没必要慌张，下面，我们一起来看看后端应该如何开发。
 
3.1、创建项目
 
为了方便快捷，小编我采用的是springboot+mybatisPlus组件来快速开发，直接利用mybatisPlus官方提供的快速生成代码的demo，一键生成所需的dao、service、web层的代码，结果如下：
 
 
3.2、编写菜单添加服务
 
@Override
public void addMenu(Menu menu) {
    //如果插入的当前节点为根节点，parentId指定为0
    if(menu.getParentId().longValue() == 0){
        menu.setLevel(1);//根节点层级为1
        menu.setPath(null);//根节点路径为空
    }else{
        Menu parentMenu = baseMapper.selectById(menu.getParentId());
        if(parentMenu == null){
            throw new CommonException("未查询到对应的父节点");
        }
        menu.setLevel(parentMenu.getLevel().intValue() + 1);
        if(StringUtils.isNotEmpty(parentMenu.getPath())){
            menu.setPath(parentMenu.getPath() + "," + parentMenu.getId());
        }else{
            menu.setPath(parentMenu.getId().toString());
        }
    }
    //可以使用雪花算法，生成ID
    menu.setId(System.currentTimeMillis());
    super.save(menu);
}

 
新增菜单比较简单，直接将数据插入即可，需要注意的地方是parent_id、level、path，这三个字段的写入，如果新建的是根节点，默认parent_id为0，方便后续递归遍历。
 
3.3、编写菜单后端查询服务
 
新建一个菜单视图实体类
 
@Data
@EqualsAndHashCode(callSuper = false)
@Accessors(chain = true)
public class MenuVo implements Serializable {

    private static final long serialVersionUID = -4559267810907997111L;

    /**
     * 主键
     */
    private Long id;

    /**
     * 名称
     */
    private String name;

    /**
     * 菜单编码
     */
    private String menuCode;

    /**
     * 父节点
     */
    private Long parentId;

    /**
     * 节点类型，1文件夹，2页面，3按钮
     */
    private Integer nodeType;

    /**
     * 图标地址
     */
    private String iconUrl;

    /**
     * 排序号
     */
    private Integer sort;

    /**
     * 页面对应的地址
     */
    private String linkUrl;

    /**
     * 层次
     */
    private Integer level;

    /**
     * 树id的路径 整个层次上的路径id，逗号分隔，想要找父节点特别快
     */
    private String path;

    /**
     * 子菜单集合
     */
    List<MenuVo> childMenu;
}

 
编写菜单查询服务，使用递归重新封装菜单视图
 
@Override
public List<MenuVo> queryMenuTree() {
    Wrapper queryObj = new QueryWrapper<>().orderByAsc("level","sort");
    List<Menu> allMenu = super.list(queryObj);
 // 0L：表示根节点的父ID
    List<MenuVo> resultList = transferMenuVo(allMenu, 0L);
    return resultList;
}

 
/**
 * 封装菜单视图
 * @param allMenu
 * @param parentId
 * @return
 */
private List<MenuVo> transferMenuVo(List<Menu> allMenu, Long parentId){
    List<MenuVo> resultList = new ArrayList<>();
    if(!CollectionUtils.isEmpty(allMenu)){
        for (Menu source : allMenu) {
            if(parentId.longValue() == source.getParentId().longValue()){
                MenuVo menuVo = new MenuVo();
                BeanUtils.copyProperties(source, menuVo);
                //递归查询子菜单，并封装信息
                List<MenuVo> childList = transferMenuVo(allMenu, source.getId());
                if(!CollectionUtils.isEmpty(childList)){
                    menuVo.setChildMenu(childList);
                }
                resultList.add(menuVo);
            }
        }
    }
    return resultList;
}

 
编写一个菜单树查询接口，如下：
 
@RestController
@RequestMapping("/menu")
public class MenuController {

    @Autowired
    private MenuService menuService;

    @PostMapping(value = "/queryMenuTree")
    public List<MenuVo> queryTreeMenu(){
        return menuService.queryMenuTree();
    }
}

 
为了便于演示，我们先初始化7条数据，如下图：
 
 
其中最后三条是按钮类型，等下会用于后端权限控制，接口查询结果如下：
 
 
这个服务是针对后端管理界面查询的，会将所有的菜单全部查询出来以便于进行管理，展示结果类似如下图：
 
 
这个图片截图于小编正在开发的一个项目，内容可能不一致，但是数据结构基本都是一致的。
 
3.4、编写用户菜单权限查询服务
 
在上面，我们介绍到了用户通过角色来关联菜单，因此，很容易想到，流程如下：
 
第一步：先通过用户查询到对应的角色；
第二步：然后再通过角色查询到对应的菜单；
第三步：最后将菜单查询出来之后进行渲染；
 
实现过程相比菜单查询服务多了前2个步骤，过程如下：
 
@Override
public List<MenuVo> queryMenus(Long userId) {
    //1、先查询当前用户对应的角色
    Wrapper queryUserRoleObj = new QueryWrapper<>().eq("user_id", userId);
    List<UserRole> userRoles = userRoleService.list(queryUserRoleObj);
    if(!CollectionUtils.isEmpty(userRoles)){
        //2、通过角色查询菜单（默认取第一个角色）
        Wrapper queryRoleMenuObj = new QueryWrapper<>().eq("role_id", userRoles.get(0).getRoleId());
        List<RoleMenu> roleMenus = roleMenuService.list(queryRoleMenuObj);
        if(!CollectionUtils.isEmpty(roleMenus)){
            Set<Long> menuIds = new HashSet<>();
            for (RoleMenu roleMenu : roleMenus) {
                menuIds.add(roleMenu.getMenuId());
            }
            //查询对应的菜单
            Wrapper queryMenuObj = new QueryWrapper<>().in("id", new ArrayList<>(menuIds));
            List<Menu> menus = super.list(queryMenuObj);
            if(!CollectionUtils.isEmpty(menus)){
                //将菜单下对应的父节点也一并全部查询出来
                Set<Long> allMenuIds = new HashSet<>();
                for (Menu menu : menus) {
                    allMenuIds.add(menu.getId());
                    if(StringUtils.isNotEmpty(menu.getPath())){
                        String[] pathIds = StringUtils.split(",", menu.getPath());
                        for (String pathId : pathIds) {
                            allMenuIds.add(Long.valueOf(pathId));
                        }
                    }
                }
                //3、查询对应的所有菜单,并进行封装展示
                List<Menu> allMenus = super.list(new QueryWrapper<Menu>().in("id", new ArrayList<>(allMenuIds)));
                List<MenuVo> resultList = transferMenuVo(allMenus, 0L);
                return resultList;
            }
        }

    }
    return null;
}

 
编写一个用户菜单查询接口，如下：
 
@PostMapping(value = "/queryMenus")
public List<MenuVo> queryMenus(Long userId){
 //查询当前用户下的菜单权限
    return menuService.queryMenus(userId);
}

 
有的同学，可能觉得没必要存放path这个字段，的确在某些场景下不需要。
 
为什么要存放这个字段呢？
 
小编在跟前端进行对接的时候，发现这么一个问题，有些前端的树型组件，在勾选子集的时候，不会将对应的父ID传给后端，例如，我在勾选【列表查询】的时候，前端无法将父节点【菜单管理】ID也传给后端，所有后端实际存放的是一个尾节点，需要一个字段path，来存放节点对应的父节点路径。
 
 
其实，前端也可以传，只不过需要修改组件的属性，前端修改完成之后，树型组件就无法全选，不满足业务需求。
 
所以，有些时候得根据实际得情况来进行取舍。
 
3.5、编写后端权限控制
 
后端进行权限控制目标，主要是为了防止无权限的用户，进行接口请求查询。
 
其中菜单编码menuCode就是一个前、后端联系的桥梁，细心的你会发现，所有后端的接口，与前端对应的都是按钮操作，所以我们可以以按钮为基准，实现前后端双向控制。
 
以【角色管理-查询】这个为例，前端可以通过菜单编码实现是否展示这个查询按钮，后端可以通过菜单编码来判断，当前用户是否具备请求接口的权限。
 
以后端为例，我们只需编写一个权限注解和代理拦截器即可！
 
编写一个权限注解
 
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface CheckPermissions {

    String value() default "";
}

 
编写一个代理拦截器，拦截有@CheckPermissions注解的方法
 
@Aspect
@Component
public class CheckPermissionsAspect {

    @Autowired
    private MenuMapper menuMapper;

    @Pointcut("@annotation(com.company.project.core.annotation.CheckPermissions)")
    public void checkPermissions() {}

    @Before("checkPermissions()")
    public void doBefore(JoinPoint joinPoint) throws Throwable {
        Long userId = null;
        Object[] args = joinPoint.getArgs();
        Object parobj = args[0];
        //用户请求参数实体类中的用户ID
        if(!Objects.isNull(parobj)){
            Class userCla = parobj.getClass();
            Field field = userCla.getDeclaredField("userId");
            field.setAccessible(true);
            userId = (Long) field.get(parobj);
        }
        if(!Objects.isNull(userId)){
            //获取方法上有CheckPermissions注解的参数
            Class clazz = joinPoint.getTarget().getClass();
            String methodName = joinPoint.getSignature().getName();
            Class[] parameterTypes = ((MethodSignature)joinPoint.getSignature()).getMethod().getParameterTypes();
            Method method = clazz.getMethod(methodName, parameterTypes);
            if(method.getAnnotation(CheckPermissions.class) != null){
                CheckPermissions annotation = method.getAnnotation(CheckPermissions.class);
                String menuCode = annotation.value();
                if (StringUtils.isNotBlank(menuCode)) {
                    //通过用户ID、菜单编码查询是否有关联
                    int count = menuMapper.selectAuthByUserIdAndMenuCode(userId, menuCode);
                    if(count == 0){
                        throw new CommonException("接口无访问权限");
                    }
                }
            }
        }
    }
}

 
我们以【角色管理-查询】为例，先新建一个请求实体类RoleDto，添加用户ID属性
 
@Data
@EqualsAndHashCode(callSuper = false)
@Accessors(chain = true)
public class RoleDto extends Role {

 //添加用户ID
    private Long userId;
}

 
在需要的接口上，添加@CheckPermissions注解，增加权限控制
 
@RestController
@RequestMapping("/role")
public class RoleController {

    private RoleService roleService;

    @CheckPermissions(value="roleMgr:list")
    @PostMapping(value = "/queryRole")
    public List<Role> queryRole(RoleDto roleDto){
        return roleService.list();
    }

    @CheckPermissions(value="roleMgr:add")
    @PostMapping(value = "/addRole")
    public void addRole(RoleDto roleDto){
        roleService.add(roleDto);
    }

    @CheckPermissions(value="roleMgr:delete")
    @PostMapping(value = "/deleteRole")
    public void deleteRole(RoleDto roleDto){
        roleService.delete(roleDto);
    }
}

 
依次类推，当我们想对某个接口进行权限控制的时候，只需要添加一个注解@CheckPermissions，并填写对应的菜单编码即可！
 
四、用户权限测试
 
我们先初始化一个用户【张三】，然后给他分配一个角色【访客人员】，同时给这个角色分配一下2个菜单权限【系统配置】、【用户管理】，等会用于权限测试。
 
初始内容如下：
 
 
 
 
 
数据初始化完成之后，我们来启动项目，传入用户【张三】的ID，查询用户具备的菜单权限，结果如下：
 
 
查询结果，用户【张三】有两个菜单权限！
 
接着，我们来验证一下，用户【张三】是否有角色查询权限，请求角色查询接口如下：
 
 
因为没有配置角色查询接口，所以无权访问！
 
五、总结
 
整片内容，只介绍了后端关键的服务实现过程，可能也有遗漏的地方，欢迎网友点评、吐槽！
 
最后说两句（求关注）
 
最近大家应该发现微信公众号信息流改版了吧，再也不是按照时间顺序展示了。这就对阿粉这样的坚持的原创小号主，可以说非常打击，阅读量直线下降，正反馈持续减弱。
 
所以看完文章，哥哥姐姐们给阿粉来个在看吧，让阿粉拥有更加大的动力，写出更好的文章，拒绝白嫖，来点正反馈呗~。
 
如果想在第一时间收到阿粉的文章，不被公号的信息流影响，那么可以给Java极客技术设为一个星标。
 
 
最后感谢各位的阅读，才疏学浅，难免存在纰漏，如果你发现错误的地方，由于本号没有留言功能，还请你在后台留言指出，我对其加以修改。
 
最后谢谢大家支持~
 
最最后，重要的事再说一篇~
 
快来关注我呀~
快来关注我呀~
快来关注我呀~
 
< END >
 
如果大家喜欢我们的文章，欢迎大家转发，点击在看让更多的人看到。也欢迎大家热爱技术和学习的朋友加入的我们的知识星球当中，我们共同成长，进步。
 
 

 
动态菜单和按钮控制-前端权限控制-RBAC模型
 
 

 
目录
 
 


 
文章目录
 
1、前文回顾
2、动态菜单
2.1、原理
2.2、对比发现问题
2.3 改造
   
3、按钮控制
3.1、原理
3.2、实现
   
4、效果展示与问题
4.1、效果展示
4.2、问题
   
***后记*** ：
 


 


 
 

 
内容
 
 
1、前文回顾
 
要实现动态菜单和按钮控制，需要菜单和按钮权限数据，这些我们在之前的博文中已实现。
 相关博文如下：
 
层级菜单生成算法
菜单和按钮权限数据封装返回
 
2、动态菜单
 
2.1、原理
 
数据库中给不同用户赋予不同的菜单权限，
用户登录获取菜单列表
前端路由加载菜单
 
2.2、对比发现问题
 
菜单的生成依赖与前端路由控制。
 
 
框架默认路由对象：
 
  {
  	path: "/zip",
  	component: Layout,
  	redirect: "/zip/download",
  	alwaysShow: true,
  	name: "Zip",
  	meta: { title: "压缩", icon: "zip" },
  	children: [
  	  {
  		path: "download",
  		component: () => import("@/views/zip/index"),
  		name: "ExportZip",
  		meta: { title: "导出压缩" }
  	  }
  	]
    }
 
 
后端返回的菜单对象：
 
  {
  	"id": "1352785556979511297",
  	"name": "companyList",
  	"path": "companyList",
  	"type": 1,
  	"orderNum": 1,
  	"pid": "1352785556979511296",
  	"hidden": false,
  	"meta": {
  	  "icon": "company",
  	  "title": "公司管理"
  	}
   }
 
 
小伙伴们发现了什么不吗？
 
是的我们自己构造的菜单对象中缺少路由对应的组件，即component属性。我们需要在控制动态菜单生成的地方自己构建。
原有路由是通过菜单对象 meta{roles: [角色]}实现动态菜单，而我们通过用户具有的菜单权限来控制。
 
通过查找我们发现路由对象数组生成方法为generateRoutes,方法位于@/store/modules/permission.js中。
 
2.3 改造
 
 
代码如下：
 
  generateRoutes({ commit }, menus) {
  	return new Promise(resolve => {
  	  // let accessedRoutes
  	  // if (roles.includes('admin')) {
  	  //   accessedRoutes = asyncRoutes || []
  	  // } else {
  	  //   let accessedRoutes = filterAsyncRoutes(asyncRoutes, roles)
  	  // // }
  	  // 生成路由
  	  let accessedRoutes
  	  menus.forEach(v => {
  		v.component = Layout
  		if(v.children && v.children.length > 0) {
  		  v.children.forEach(c => {
  			c.component = (resolve) => require(["@/views/" + v.name + "/" + c.name],resolve)
  		  })
  		  // "@/views/" + v.name + "/" + c.name
  		}
  	  })
  	  accessedRoutes = menus
  	  commit('SET_ROUTES', accessedRoutes)
  	  resolve(accessedRoutes)
  	})
    }
 
 
解析：
 
  
原有component通过import 来动态烂加载路由组件，这里我们构建后会报错，具体原理不是很清楚，我们改又ES5语法require实现
 
 
3、按钮控制
 
3.1、原理
 
数据库不同用户赋予不同的按钮权限-字符串标志
用户登录获取按钮权限数组
判断是否又权限，按钮组件v-if来控制显示与否
 
3.2、实现
 
因为登录之后又很多页面，每个页面又很多的按钮，而判断逻辑都一样，所有我们把判断逻辑封装为方法，挂在到Vue示例上，具体代码如下：
 
import store from './store'
...
Vue.prototype.$hasPerm = (perm) => {
  let btns = store.getters.btns
  if (btns && btns.length > 0) {
   return btns.includes(perm)
  }
  return false
}
 
这里简单列举一个按钮示例：
 
 <el-button
		class="filter-item"
		style="margin-left: 10px;"
		type="primary"
		icon="el-icon-edit"
		@click="handleCreate"
		v-if="$hasPerm('sys:company:save')"
	  >
		添加
</el-button>
 
4、效果展示与问题
 
4.1、效果展示
 
 
管理员用户登录界面：
 
 
 
其他某个用户登录：
 
 
 
4.2、问题
 
main.js作为入口，代码越简洁越好，我们把判断按钮显示与否的方法写在main.js中
按钮权限控制，我们是在具体的每个按钮组件处判断，且与权限标志字符串，比如’sys:company:save’耦合在一起，不利于后期修改
 
问题2暂时没想到比较好的解决办法，问题1后面有空优化以下。其中非重要的页面列表和详情，默认所有用户都可以查看，即没有加权限。
 
后记 ：
 
本项目为参考某马视频开发，相关视频及配套资料可自行度娘或者联系本人。上面为自己编写的开发文档，持续更新。欢迎交流，本人QQ:806797785
 
后端JAVA源代码地址:https://gitee.com/gaogzhen/ihrm-parent    // 后端项目
前端项目源代码地址：https://gitee.com/gaogzhen/ihrm-vue    // 前端后台管理系统

一.菜单访问权限控制
 
配置helloword菜单【系统管理】-【菜单管理】 
 
其中前端组件配置相对src/views/目录下的 目录名+文件名
例如页面src/views/jeecg/helloworld.vue 前端组件配置 jeecg/helloworld
 用户角色授权【系统管理】-【角色管理】-授权  点击菜单访问页面展示Hello World!
 
二.表单访问权限控制
 
禁用控制用法二
 
一、用法
 
（1）页面引入工具js
 
import { disabledAuthFilter } from "@/utils/authFilter"
 
(2)methods方法中实现：
 
isDisabledAuth(code){
      return disabledAuthFilter(code);
    },
 
 
 
（2）权限控制代码示例：
 

<a-input-number :disabled="isDisabledAuth('name')"   v-decorator="[ 'days', {}]" />
 
二、权限配置：
 
 
三、使用说明
 
:disabled="isDisabledAuth('name')"调用方法disabledAuth，方法参数“name”为授权标识，该方法根据授权规则返回true/false，控制是否禁用
权限编码在【系统管理--菜单管理】中配置，添加按钮类型的菜单数据，授权标识配置值“name”，策略选择可编辑，状态选择有效
控制规则：
（1）菜单权限中若没有对应指令编码的配置，则不进行禁用控制，
（2）权限配置无效状态时，则不进行权限控制，有效状态时进行控制
（3）策略：可编辑，未授权时控件禁用，授权后可编辑
四、流程节点权限
 
（1）说明：
 
节点权限配置优先级高于菜单权限配置
节点权限应用于使用组件方式加载的附加表单页面，并对附加表单页面进行权限控制
显示控制用法见上面用法描述
 
节点权限是通过 props: ['formData'],来传递给节点表单页面的，因此页面一定要定义这个，否则，节点配置的权限不生效，节点表单开发方法见【流程节点对接表单页面开发方法】
 
 
权限配置无效状态时，则不进行权限控制，有效状态时进行控制
 
(2)methods方法中实现： 
isDisabledAuth(code){
      return disabledAuthFilter(code,this.formData);
    },
 
（2）权限配置： 在【流程管理-流程设计】中找到需要配置的流程，进入【流程配置-流程节点】选择需要进行权限控制的节点， 点击【更多-权限设置】，新增/编辑 来配置权限。
 
 
三.页面按钮权限用法
 
页面按钮权限用法
 
1.前端页面通过使用指令 v-has
 
<a-button @click="handleAdd" v-has="'user:add'" type="primary" icon="plus">添加用户</a-button>
 
2.后台进入菜单管理页面配置按钮权限菜单 
 
3.进入角色管理授权按钮（授权后即可看见按钮） 
 
四.JAVA访问权限控制
 
1.后台请求权限控制，通过Shiro注解 @RequiresPermissions
 
@RequestMapping(value = "/add", method = RequestMethod.POST)
@RequiresPermissions("user:add")
public Result<SysUser> add(@RequestBody JSONObject jsonObject) {
 
2.后台进入菜单管理页面配置访问权限标识（选择按钮类型） （配置方式与按钮权限一样，即同一个授权标识，可以同时控制后台请求和前台按钮显示控制） 
 
3.进入角色管理授权访问权限（授权后即可访问该请求） 
 
五.数据权限规则篇
 
 
 
1、功能说明
 
列表数据权限，主要通过数据权限控制行数据，让不同的人有不同的查看数据规则； 比如： 销售人员只能看自己的数据；销售经理可以看所有下级销售人员的数据；财务只看金额大于5000的数据等等；
 
2、数据权限分两大类型
 
序号
类型
规则字段区别
说明
1
编码方式
规则字段是驼峰写法，对应mybatis实体的字段
编码模式（通过代码生成器生成代码）
2
Online方式
规则字段是下划线写法，对应表的字段
Online模式（在线表单模式，无代码）
规则字段配置说明（非常重要）： 
①条件规则：大于/大于等于/小于/小于等于/等于/包含/模糊/不等于
②规则值：指定值 ( 固定值/系统上下文变量 )
 
3、数据权限规则篇
 
1.当前用户上下文变量
 
注意：数据权限配置，规则值可以填写系统上下文变量（当前登录人信息），从而根据当前登录人信息进行权限控制。
 
编码
描述
sys_user_code
当前登录用户登录账号
sys_user_name
当前登录用户真实名称
sys_date
当前系统日期
sys_time
当前系统时间
sys_org_code
当前登录用户部门编号
sysMultiOrgCode
当前登录用户拥有的所有机构编码，逗号分隔
规则值，配置写法如下：#{sys_user_code}
 
2.建表规范（系统标准字段）
 
如果需要通过当前登录人，进行数据权限控制，则业务表必须有以下系统标准字段；数据添加和编辑，jeecg会通过拦截器自动注入操作人的信息。 比如：创建人，创建时间，创建人所属部门、创建人所属公司，有了这些标准字段，就可以通过当前登录人进行数据隔离控制；
 
字段英文名
字段中文名
CREATE_BY
系统用户登录账号
CREATE_NAME
系统用户真实名字
SYS_ORG_CODE
登录用户所属部门
3.组织机构邮编规则
 
JEECG组织机构支持无限层级，上下级关系通过组织机构编码实现，组织机构编码规则类似邮编方式，看下图； 邮编规则优势： 邮编规则，上下级编码固定规律，便于定位下级和上级； 
 
六.系统数据权限用法
 
 
 
1、功能说明
 
 
 
列表数据权限，主要通过数据权限控制行数据，让不同的人有不同的查看数据规则； 比如： 销售人员只能看自己的数据；销售经理可以看所有下级销售人员的数据；财务只看金额大于5000的数据等等；
 
 
2、使用说明 （有两种使用方法，以下说明以用户管理列表查询示例 配置数据规则:只查询用户账号带1的用户）
 
方法A步骤如下:
 
A-1.新增权限菜单：进入【系统管理】-->【菜单管理】界面 新增一个权限菜单(如下图)
 
A-2.配置数据权限规则：找到上述1新增的菜单,点击操作列更多中的数据规则,配置,只查询用户账号带1的用户(如下图) 
A-3.角色授权：进入【系统管理】-->【角色管理】界面找到当前用户对应的角色，点击 更多->授权 操作，右侧弹出框中找到上述1菜单，点击后勾选权限规则,保存(如下图) 
A-4.在后台请求方法上加注解@PermissionData在方法上加注解是为了提高系统运行效率,这样就可以指定请求走权限过滤的逻辑,而非一棍子打死,让所有请求都去筛选一下权限(如下图) 
A-5.测试,访问用户管理界面发现数据被过滤了,即权限生效!
 
 
方法A的问题在于,每个请求都需要配置一个权限菜单,这样其实也很费劲,同时对于菜单管理也不是很好,鉴于此可以考虑使用方法B 方法B基于注解属性pageComponent,步骤如下：
 
 
B-1.找到需要配置权限的页面菜单,这里是用户管理菜单
 直接在该菜单上配置数据规则(如A-2)
 
B-2.角色授权（如A-3）
B-3.添加注解 (如A-4,不同的是注解上增加了一个属性)@PermissionData(pageComponent="system/UserList")pageComponent的值和B-1中菜单的前端组件值保持一致
B-4.测试,访问用户管理界面发现数据被过滤了,即权限生效!
规则字段配置说明（非常重要）： 
①条件规则：大于/大于等于/小于/小于等于/等于/包含/模糊/不等于/自定义SQL
②规则值：指定值 ( 固定值/系统上下文变量 )
 
3、数据权限规范说明
 
1.系统上下文变量
 
注意：数据权限配置，规则值可以填写系统上下文变量（当前登录人信息），从而根据当前登录人信息进行权限控制。
 
编码
描述
sys_user_code
当前登录用户登录账号
sys_user_name
当前登录用户真实名称
sys_date
当前系统日期
sys_time
当前系统时间
sys_org_code
当前登录用户部门编号
规则值，配置写法如下：#{sys_user_code}
 
2.建表规范（系统标准字段）
 
如果需要通过当前登录人，进行数据权限控制，则业务表必须有以下系统标准字段；数据添加和编辑，jeecg会通过拦截器自动注入操作人的信息。 比如：创建人，创建时间，创建人所属部门、创建人所属公司，有了这些标准字段，就可以通过当前登录人进行数据隔离控制；
 
字段英文名
字段中文名
CREATE_BY
系统用户登录账号
CREATE_NAME
系统用户真实名字
SYS_ORG_CODE
登录用户所属部门
3.组织机构邮编规则
 
JEECG组织机构支持无限层级，上下级关系通过组织机构编码实现，组织机构编码规则类似邮编方式，看下图； 邮编规则优势： 邮编规则，上下级编码固定规律，便于定位下级和上级；