之前在基于Vue實現(xiàn)后臺系統(tǒng)權(quán)限控制一文中提到路由權(quán)限的實現(xiàn)思路，因為不喜歡在每次路由跳轉(zhuǎn)的before鉤子里做判斷，所以在初始化Vue實例前對路由做了篩選，再用實際路由初始化Vue實例，代價是登錄頁需要從Vue實例中獨立出來，實現(xiàn)上倒沒什么問題，不過這種做法需要在登錄和首頁之間通過url跳轉(zhuǎn)，感覺總是不太”優(yōu)雅”，實際上只要能在登錄后動態(tài)修改當前實例的路由就行了，之前確實沒辦法，但vue-router 2.2版本新增了一個router.addRoutes(routes)方法，讓動態(tài)路由得以實現(xiàn)。

想當然的實現(xiàn)方案

用動態(tài)路由實現(xiàn)路由權(quán)限控制貌似是一個完美的方案，初始路由只有登錄和404，登錄后動態(tài)添加可用路由，同時將菜單數(shù)據(jù)保存到Vuex或本地用于實現(xiàn)動態(tài)菜單，關(guān)鍵節(jié)點大致如下：

//初始路由：
[{
 path: '/login',
 name: 'login',
 component: (resolve) => require(['../views/common/404.vue'], resolve)
}, {
 path: '/404',
 name: '404',
 component: (resolve) => require(['../views/common/404.vue'], resolve)
}, {
 path: '*',
 redirect: '/404'
}]

//登錄邏輯
let vm = this;
axios.get('/login', vm.user).then((res) => {
  let extendsRoutes = filterRoutes(res.menus); 
  <!--
  //假設(shè)得到的可用路由如下
  [{
   path: '/',
   name: '首頁',
   component: (resolve) => require(['../views/index.vue'], resolve),
   children: [{
    path: '/menus',
    name: '菜單管理',
    component: (resolve) => require(['../views/menus.vue'], resolve)
   }, {
    path: '/resources',
    name: '資源管理',
    component: (resolve) => require(['../views/resources.vue'], resolve)
   }]
  }]-->
  //存菜單
  sessionStorage.setItem('menus',JSON.stringify(extendsRoutes[0].children));
  //動態(tài)添加路由
  vm.$router.addRoutes(extendsRoutes);
  //跳轉(zhuǎn)到應用界面
  vm.$router.push({path:'/'});
})

//首頁獲取菜單數(shù)據(jù)
this.menus = JSON.parse(sessionStorage.getItem('menus')); 
//用此數(shù)據(jù)循環(huán)菜單
..

目前為止看上去一切順利，然而前方有坑。

動態(tài)路由的坑

第一個坑是，如果你將這套邏輯實現(xiàn)之后會發(fā)現(xiàn)打開應用看到的第一個頁面是404，這是因為啟動服務(wù)后將默認打開首頁'/‘，然而初始路由中沒有這個路徑，因此根據(jù)路由規(guī)則跳轉(zhuǎn)到了404。我們希望結(jié)果當然是跳轉(zhuǎn)到'/login'，因此需要對這種情況做判斷，在用戶登錄之前所有請求都要指向'/login'，這個判斷可以在before鉤子里做也可以在根組件里做，建議做在根組件的created回調(diào)里，核心代碼大概這樣：

let isLogin = sessionStorage.getItem('user');
if(!isLogin){
  return this.$router.push({path:'/login'});
}

這時候已經(jīng)可以順利登錄了，登錄后很快就會發(fā)現(xiàn)第二個坑，手動刷新頁面又會跳到404，這是因為刷新會導致Vue重新實例化，路由也恢復到了初始路由，于是當前路徑又被重定向到了404，這個問題的根源是可用路由沒有實現(xiàn)持久化，那么可以通過將路由數(shù)據(jù)存sessionStorage來解決，實例化之前如果檢測到本地路由就直接合并路由，像這樣：

//檢測本地路由
let localRoutes = sessionStorage.getItem('routes');
if(localRoutes){
  router.addRoutes(JSON.parse(localRoutes));
}
//實例化
new Vue({
 el: '#app',
 router,
 render: h => h(App)
});

理論上可以，但實際操作要遠比上述代碼復雜，因為存在本地的只能是權(quán)限數(shù)據(jù)而不是真實路由，路由在存、取之前都要先根據(jù)權(quán)限匹配獲得，過程還是挺繁瑣的，而且必須依賴sessionStorage這種持久存儲，沒有其他方法。問題就出在這個sessionStorage上，原則上權(quán)限只能在內(nèi)存變量中流轉(zhuǎn)，不能直接暴露到用戶可操作的地方，試想只要用戶手動修改了sessionStorage里的權(quán)限，再刷新一下頁面就能突破前端路由控制了，非常的不靠譜。

改進方案

既然不能存本地，那就每次刷新都重新從服務(wù)端獲取，所以改進后的方案是本地存用戶token，每次刷新要憑token從服務(wù)端重新獲取用戶信息和權(quán)限，然后動態(tài)更新路由，獲取權(quán)限操作可以跟登錄檢測一起放在根組件的created回調(diào)中進行，確保訪問任何路徑都會先執(zhí)行這一步，但因為獲取權(quán)限是異步操作，在此之前仍然會經(jīng)過應用初始化，所以還是會遇到404的問題，為此我們只需做一個小調(diào)整，將不匹配路徑(‘*')跳404的路由從初始路由中移除，動態(tài)更新路由時再把這個配置加進去，如下：

let userPath = ...//我們的動態(tài)路由
//注入時拼接404處理路由
this.$router.addRoutes(userPath.concat([{
 path: '*',
 redirect: '/404'
}]));

這樣就解決了刷新問題，后面還有幾個小問題就簡單了。

首先是菜單，之前通過$router.options.routes訪問路由數(shù)據(jù)實現(xiàn)動態(tài)菜單，但這個數(shù)據(jù)不是響應式的，無法追蹤動態(tài)路由的變化，因此我們需要將得到的導航菜單數(shù)據(jù)存到sessionStorage或Vuex里實現(xiàn)數(shù)據(jù)共享。

資源權(quán)限控制也受到很大的影響，實現(xiàn)較為細致的權(quán)限控制需要一個自定義權(quán)限驗證指令和一個全局驗證方法，之前的方案里權(quán)限是在Vue實例化之前獲取的，所以可以很方便的拿到權(quán)限后實現(xiàn)驗證方法，然后用驗證方法實現(xiàn)自定義指令，再將方法全局混合進Vue，然后實例化，這樣實例中的 所有組件都可以使用自定義指令和驗證方法；但現(xiàn)在的方案是先實例化再獲取權(quán)限，實例化之前根本沒有權(quán)限數(shù)據(jù)，所以自定義指無法實現(xiàn)，等拿到權(quán)限后實現(xiàn)了驗證方法，卻無法再全局混合了。

這個問題最后也解決了，但解決方案就徹底的”有辱斯文”了，首先是全局方法的實現(xiàn)，直接這么做:

Vue.prototype.has = function(){
  ...
}

使用方式跟全局混合的方法完全一樣。

自定義指令的實現(xiàn)本來很頭疼，因為全局指令只能在實例化之前實現(xiàn)，但那時候又確實沒有權(quán)限，不過既然驗證方法這么做的話，指令倒是也順便解決了，像這樣：

//權(quán)限指令
Vue.directive('has', {
 bind: function(el, binding) {
  if (!Vue.prototype.has(binding.value)) {
   el.parentNode.removeChild(el);
  }
 }
});

神奇的prototype貌似自帶惰性效果，可以先注冊后實現(xiàn)，具體原因我也不太明白，如過有大牛路過，希望能留下答案。

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論