前端根据登录用户做不同权限控制

对于大部分管理后台而言，角色权限都是一个重要的环节。通过角色权限的配置，我们可以轻松的调整各个用户所拥有的各个模块或者说页面的权限，从而让用户只能访问到对应权限的页面。

通俗易懂的来说，就是哪些页面是向所有用户开放的，哪些是需要登录后才能访问的，哪些是要拥有xx角色权限才能访问的等等(这里的xx指的是管理员、普通成员等这些的角色)。

在后台管理系统中角色权限的方案设计是很重要的。

• 其一，好的设计能为后面新增的模块或者说页面省下很多功夫。
• 其二，好的设计能为之后的拓展功能(比如权限具体控制某个按钮等)提供更多的维护和设计思路。
• 其三，好的设计可使代码可读性更强，更能一眼区分开权限代码与业务代码。

对于角色权限而言，真正进行把关的是应该是后端。首先是因为前端的相关代码校验是可以被数据造假通过的，安全性并不高。其次，在一个系统中前端所调用的接口是不应该被无权调用通过并且返回数据的。因此接口这块后端必须严格根据权限去控制，谨防无权限直接调用得到数据返回。简而言之就是即使前端没有把控页面和权限，用户也不能够获取没有权限的页面或者模块的相关数据和操作的，后端应该是可以判断他越权访问并拒绝返回数据的。但是若无前端把控，那这样整个系统的体验将会很糟糕，比如访问无权限页面时各种报错问题等等。因此前端在角色权限中更多职责的应是完善用户的交互体验。

角色权限控制的整个流程中，前端整个流程步骤应是首先展示无需登录的默认页面（比如404页面、登录页、注册页），然后在登录或浏览器刷新时调用后端接口拿到后端给的该账户的权限数据，然后将数据注入到系统中，整个系统拿到权限数据后就开始对页面的展现内容以及页面导航进行生成，最终生成一个只展示当前用户所拥有对应权限的系统。从而达到整个角色权限的控制。综上所述，前端在角色权限中更多职责的应是完善用户的交互体验。

从下面三个方面，讲述前端角色权限的实现

• 登录权限控制
• 角色权限控制
• 内容权限控制

登录权限控制

登录权限控制，简而言之就是实现哪些页面能被未登录的用户访问，哪些页面只有用户登录后才能被访问。

实现这个功能也很简单，下面例举出 2 种常见的实现方案。

第一种为将无需登录的页面路由放在一起，代码如下：

let invisible = [
  {
    path: '/login', //登录页面
    name: 'Login',
    component: Login,
  },
  {
    path: '/404',
    name: 'index-notFount',
    component: () => import('@/pages/core/NotFount/index'),
  },
];
 
export default invisible;

 定义一个invisible数组，数组中包含着所有无需登录就可以查看的页面路由。

// 引入无需登录的页面
  import invisible from './invisible';
 
  let router = new Router({
    routes: [
      ...invisible,
    ],
  });
 
  const invisibleMap = [];
  invisible.forEach(item => {
    if (item.name) {
      invisibleMap.push(item.name);
    }
  });
 
  router.beforeEach(async (to, from, next) => {
    if (!invisibleMap.includes(to.name)) {
        // 业务逻辑判断登录等
    }
    else {
      next();
    }
  })

 引入invisible，路由名称映射到invisibleMap数组上，在路由守卫中拦截判断。由此做到无需登录的页面可以直接查看(放在invisible数组中)，需要登录的页面则会进行登录等业务判断。

除上述方法外，也可在路由对象中以添加meta的方式去实现登录页面权限控制，相关代码如下：

export const routes = [
      {
         path: '/login', //登录页面
         name: 'Login',
         component: Login,
      },
      {
         path:"/list", // 列表页
         name:"List",
         meta:{
            need_login:true //需要登录
         }
      }
    ]

 代码如上所示，登录页面由于无需登录，因此可不用设置meta.need_login属性，然而列表页面需要登录，因此设置need_login属性。

同第一种方式一样，真正的拦截在路由守卫之中，代码如下：

router.beforeEach((to, from, next) => {
  if (to.meta.need_login) {
    // 业务逻辑判断登录等
      
  } else {
    next();
  }
});

此处拿到need_login字段，判断是否为需要登录的路由页面，如若是，则进行下一步登录逻辑判断等，如若不是，则可放行。

角色权限控制

在讨论角色权限控制之前，我们应该先清楚一个点：在引入了角色概念的系统中，任何该系统中的账号都应该至少拥有一个或几个角色身份，这样该账号就拥有当前这一个角色(或几个角色)的相关权限功能。简而言之，我们不会直接把权限赋予给用户，而是通过角色来赋予给用户。角色权限控制主要是解决给不同角色赋予不同权限从而赋予不同账户权限，接下来先了解一下角色的概念。

在某个系统当中，存在3个比较普遍性的角色：普通成员、管理员以及超级管理员。普通成员能够浏览系统的 a、b、c 三个模块，但是它不能查看和编辑 d、e 模块(假设只有d、e模块可编辑)。管理员拥有普通会员的所有权限，另外它还能查看 d、e 模块和编辑d模块。超级管理员拥有此系统的所有权限，因此相比于管理员而言，在这就多出一个编辑e模块。

当然，就上述而言，都是一些简单的角色划分。本文不在此做更多的深讨。

那么角色权限，在设计上能否以前端为主导呢?(即后端只为账号标识为某某角色，控制角色权限这块由前端主导)

我们通过一个简单的例子来回答上述问题。

我们暂且根据以上的较为普遍的角色来做简单设计。

export const permission = {
   member:["Home"], //普通成员
   admin:["Home" ,"Notify"],  // 管理员
   super_admin:["Home" ,"Notify","Manage"]  // 超级管理员
 }

在上述角色权限中，普通成员拥有首页权限，管理员拥有首页、通知权限，超级管理员则还额外拥有管理的权限。

如果以前端为主导，那么后端则应是在登录接口返回当前账户所属哪些角色。拿到该账号的角色后后就去上面的配置文件里取出该角色所能访问的页面权限，随后将这部分页面权限加载到系统中从而达到权限控制的目的(需要注意的是，数组里面的值应和对应页面的路由名称相匹配)。

在上述设计中，后端只负责给账户标识对应角色，并且写入库中，在登录时返回给前端此账户对应的角色。到了这一步，可能会有同学存在疑问，这样不是也挺好的吗，前端不也可以控制角色权限嘛。别急，那现在来思考一个问题。如果对一个已上线的系统项目，现需要紧急新增一个角色比如x，那么前端就要急需修改配置文件(配置文件如上图)，此时还不够，还需把之前的y用户移动到x角色下，那么此时不光是前端要改配置文件，后端也需要在库中把y用户移动到x角色下。这样的改动显得非常容易出错且复杂。

综上所述，在角色权限这块，其实最好的办法就是交给后端去配置，有哪些角色，账户对应哪些角色这些逻辑应当是后端负责，后端通过登录直接返回该账户所拥有的权限，前端这块无需过度关注角色主要职责应是根据后端的权限返回，展示对应的权限页面和菜单。这样即使碰到上述的修改也能轻便灵巧的解决。

以下介绍角色权限的方案。

如后端返回的账户权限结构如下：

{
   "home": {
     "id":"100",
     "name":"home",
     "desc":"首页",
     "value":true,
     "children": [],
   }
 }

 

在这个权限结构之中，id为页面或者说模块的唯一标识id，name此处最好与前端路由页面对象的name值相对应，desc为菜单上展示的名称，value代表这个模块或者页面是否展示，children数组为此页面的二级页面数组，对于路由的权限控制和菜单的渲染生成都有着重要的影响。

在此结构中，前端通过判断 value 来决定这个页面是否有权限展示，children 下为当前页面或者说模块下的二级页面，三级页面等，结构跟 home 应是一样的。如若一级页面value为false，那下面的二级、三级应当都无权展示。

此时前端需要做的是递归遍历后端返回的这个结构，当判断value为 false 的时候，把对应到的路由页面给过滤掉。

 
// 生成过滤路由和菜单的方法  
function filterRouter(arr, obj, type) {
  if (Array.isArray(obj)) {
    // 数组处理
    obj.forEach(item => {
      handleRouterItem(arr, item, type);
    });
  } else {
    // 对象处理
    for (let item in obj) {
      handleRouterItem(arr, obj[item], type);
    }
  }
}
 
// 处理每个元素节点
function handleRouterItem(arr, item, type) {
  // 确定这个页面或模块是不展示的
  if (item.value === false) {
    if (type === 'menu') {
      assistance(arr, routerMap[item.name]);
    } else {
      assistanceRouter(arr, routerMap[item.name]);
    }
  } else if (item.childrens && item.childrens.length > 0) {
    filterRouter(arr, item.childrens, type);
  }
}
 
function assistanceRouter(arr, name, obj) {
  for (let i = 0; i < arr.length; i++) {
    if (arr[i].name === name) {
      // 无权限页面设置meta字段或者直接删除
      // arr.splice(i, 1);
      Vue.prototype.$set(arr[i].meta, 'hasRoleAuth', false);
      return true;
    } else {
      if (arr[i].children && arr[i].children.length > 0) {
        if (assistanceRouter(arr[i].children, name, arr[i])) {
          return;
        }
      }
    }
  }
}
 
function assistance(arr, name, obj) {
  for (let i = 0; i < arr.length; i++) {
    if (arr[i].name === name) {
      arr.splice(i, 1);
      return true;
    } else {
      if (arr[i].children && arr[i].children.length > 0) {
        if (assistance(arr[i].children, name, arr[i])) {
          return;
        }
      }
    }
  }
}
 
export const rolePermission = () => {
  // router为所有页面的路由结构，roleRouter为后端返回的角色权限对象
  filterRouter(router, roleRouter);
  router.addRoutes(router);
}