基于Vue实现后台系统权限控制
正文
用Vue这类双向绑定框架做后台系统再适合不过，后台系统相比普通前端项目除了数据交互更频繁以外，还有一个特别的需求就是对用户的权限控制，那么如何在一个Vue应用中实现权限控制呢？下面是我的一点经验。
权限控制是什么
在权限的世界里服务端提供的一切都是资源，资源可以由请求方法+请求地址来描述，权限是对特定资源的访问许可，所谓权限控制，也就是确保用户只能访问到被分配的资源。具体的说，前端对资源的访问通常是由界面上的按钮发起，比如删除某条数据；或由用户进入某一个页面发起，比如获取某个列表数据。这两种形式覆盖了资源请求的大部分场景，因此权限控制也可以被笼统的分成菜单权限控制和按钮权限控制。
Vue菜单权限控制
菜单是对路由的直接体现，菜单控制实际上就是路由控制。实现路由控制一个简单的方式是，在路由的before钩子里校验当前即将跳转的路由地址是否有权访问，根据校验结果决定路由是否放行，伪码：
1 2 3 4 5 6 7 8 |
router.beforeEach((to, from, next) => {
//权限校验
let pass = valid(to);
if(!pass){
return console.log('无权访问');
}
next();
});
|
这种实现方式既简单又直观，用于路由总数不多的系统非常合适，但这么做本质上是将所有路由全部注册了，直接带来的缺点有两个：一、如果路由组件不是按需加载的话，应用将加载大量冗余代码；二、每次跳转都要遍历一次完整路由，是对计算能力的浪费。
理想的实现方式是本地保存完整路由，但并不立即初始化Vue应用，待用户登录拿到权限后，用菜单权限筛选出可用路由，再用可用路由初始化Vue应用。也就是说，要将登录页独立出去做成一个单独的页面，登录后将用户数据保存在本地，再通过url跳转到Vue应用所在页面，Vue应用启动前通过本地用户数据完成路由筛选，然后初始化Vue应用，伪码如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
//main.js
let user = sessionStorage.getItem('user');
if (user) {
user = JSON.parse(user);
//筛选得到实际路由
let fullPath = require('fullPath.js');
let routes = filter(fullPath, user.menus);
//创建路由对象
let router = new Router({routes});
//生成Vue实例
new Vue({
el: '#app',
router,
render: h => h(App)
});
}else{
location.href = '/login/';
}
|
这时我们还希望能直接用路由数据生成导航菜单，常规的路由数据可能无法满足菜单组件的需求，所以我们要事先在路由的meta里维护上菜单数据，比如菜单名称菜单图标等，只要在模板中通过$router.options就可以访问到当前路由数据，如果使用element-ui的菜单组件实现，代码大致是这样的：
1 2 3 4 5 6 7 |
|
当然这样只能循环出一级菜单，如果还有二级路由需要对应二级菜单的话，就得判断并循环children节点，比较简单就不放更多代码了，菜单权限控制到这里就完成了。
Vue按钮权限控制
按钮权限控制与菜单权限控制的实现思路类似，也是根据用户权限判断各个按钮的显示与否，方式无非是v-if或自定义指令，而且只要将v-if背后的权限校验逻辑抽象成方法，无论是代码量还是使用形式上都跟自定义指令几乎一样，但v-if的特点是它会响应数据变化，因此随着应用的运行会频繁触发权限校验，而权限在应用的整个生命周期内其实只需校验一次，为了避免无谓的程序执行，这里可以用自定义指令来实现，伪码:
1 2 3 4 5 6 7 8 9 10 |
Vue.directive('has', {
bind: function (el, binding) {
if(!has(binding.value)){
el.parentNode.removeChild(el);
}
}
});
//用法：
|
注意在指令bind回调里有一个has()方法，这就是权限校验方法，我们同时将这个方法全局混合到Vue对象中，使应用里的每个组件都可以访问到这个方法，便于为界面上的v-if提供支持，例如：
1 2 3 |
|
验证方法的实现不是本文重点，只讲大致思路，假设服务端用请求方法+请求url定义资源，如”get,/resources”，那么资源权限数据应该是由于资源组成的数组，我们需要先将数组转换成对象格式，如：
1 2 3 4 5 6 7 |
let permissions = {
"get,/resources":true,
"delete,/resources":true,
"post,/resources":true,
"put,/resources":true,
...
}
|
在验证方法里就可以通过直接访问permissions的属性来确定是否拥有权限，效率远高于遍历原始权限数组，代码应该是这样的：
1 2 3 4 5 6 |
let has = function(permission){
if(!permissions[permission]){
return false;
}
return true;
}
|
这样一来凡是需要依据权限实现的按钮显隐控制和界面变化都可以很方便的实现。
但做按钮权限麻烦的地方不在于如何实现，而在于高昂的维护成本。我们假设按钮Btn绑定了点击回调Fn，回调Fn里发起了请求Req，请求Req需要某个资源的访问权限，最终你要根据用户是否拥有Req的权限决定Btn是否显示，而Req跟Btn之间并没有直接关联，所以我们就要人肉维护他们的关系，一个复杂项目里的按钮有个几十上百都很正常，随着业务的变更去维护这么多按钮的权限，想想都头疼。
有一个方法可以绕开这个烂摊子，那就是前端放弃对视图层的控制，退到请求层面，在请求发起前集中拦截，这时可以直接根据请求方法和请求地址来校验权限，除了实现一个拦截器之外不需要额外的代码，可以说非常优雅了。以axios为例，拦截器大概长这样：
1 2 3 4 5 6 7 8 9 10 |
axios.interceptors.request.use(function (config) {
let permission = config.method + config.url.replace(config.baseURL,',');
if(!has(permission)){
//验证不通过
return Promise.reject({
message: `no permission`
});
}
return config;
});
|
但如果仅仅这样做权限控制，界面上将显示出所有的按钮，用户看到的按钮却不一定可以点击，这种体验我认为只能停留在理论层面，根本无法应用到实际产品中。请求控制可以作为整个控制体系的第二道防线，或某些特殊情况下的辅助手段，最终还是要回到按钮控制的思路上来。
那么怎样能尽可能方便的采集到每个按钮所需的权限呢？按钮和权限之间隔着两层东西，第一层是click回调，第二层是回调里的AJAX请求，不想人肉维护就得想办法突破这两层隔阂，让按钮和权限产生联系，按钮必然要绑定click事件，最理想的采集方式是在绑定事件的同时得到所需权限，让一切自然而然的发生，比如我们可以实现一个完美的v-do指令，
1 |
|
如果Fn能以某种形式采集到内部的AJAX请求参数，并转化成权限信息传递出来就完美了，然而我没找到可行的方法，并且这种形式在应用上也存在缺陷，因为不一定每个操作按钮都会发起AJAX请求，比如编辑按钮本身并不会触发请求，真正触发请求的是另一个保存按钮，所以这个思路只是看起来很美。
退而求其次的做法是让按钮和请求联系起来，比如说按钮涉及一个名称为A的请求，那么我希望权限指令可以这样写，
1 |
|
比完美形态是差了不少，但起码不需要手动维护到'get,/resources'这个级别了，这里对A的实现可以有多种形式，比如A可以是一个包含两个属性的对象：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
const A = {
p: ['put,/menu/**'],
r: params => {
return axios.put(`/menu/${params.id}`, params)
}
};
//用作权限：
|
通常我们会将项目里所有的api放在一个api模块里集中管理，在写api时顺便就把权限给维护了，换来的是在组件界面里可以直接用请求名称来描述权限，而不需要来回奔波于界面和api模块之间，一定程度上实现了关注点分离，而且has指令还可以进一步做优化，例如参数只需要接收A，指令内部根据约定自动访问A.p来获取权限，还可以接收数组，允许多个权限联合校验，尽可能降低按钮权限的维护成本。
后记
总结一下，因为我的项目包含了管理端和客户端的所有功能，角色差异比较大，因此路由权限没有在before钩子里做，而是在登录后启动前进行路由筛选，省去了每次都要在before钩子里做校验的麻烦；按钮权限使用自定义指令实现，并且将验证方法全局混入，便于在界面上使用v-if；最后为axios设置拦截器，作为权限控制的第二道防线。
好了，这就是我对前端权限控制的一些实践和思考，如有不当欢迎指正。
最后吐槽一下Element-UI，真心难看。