基於vue(element ui) + ssm + shiro 的權限框架。javascript
領悟,理解,消化它!前端
如今的Java世界,各類資源很豐富,不得不說,從分佈式,服務化,orm,再到前端控制,權限等等玲琅滿目,網上有句話說,語言框架迭代太快了,我學不動了,不如回去搬磚吧,但是天這麼熱,磚燙手啊。程序搞起來很容易,就是有點頭冷。
<div align="center"> <img src="http://p94g7wqy4.bkt.clouddn....; width="400"/> </div>
vue
語言框架迭代太快,沒錯,就簡單來講高級語言就有幾十種,雖然流行的就那麼幾種,語言就是重複之一,從語言想表達的做用上來看,都是爲了操做計算機,我想將來計算機語言的前景多是語言一體化,固然,這是個很漫長的路,相信一些語言的創造者,當初也是對某語言不滿意,而後就去改造,可是其實絕大部分仍是重複的,這一方面,我深有體會,當初,僅僅爲了更好地學習MVC框架原理,以爲最好的學習就是重寫它,最後,好比hulichao_framework下面的oliver就是結果的殘品,只是實現了基本的從頁面處處理端的映射,以及處理返回,其實想一想也比較簡單,尤爲是原理,就是頁面與控制器更好地處理與映射,固然完美重寫,我沒有這樣幹,如今流行的開源mvc框架已經不少了,另一個就是簡單重構過orm框架hulichao_framework下面的yBatis,實現了什麼呢,就是數據庫與Java程序之間的相互映射,同時約定固定方法開頭的能夠不須要寫sql語句,想說明什麼問題呢,其一,我在重複造輪子,固然在這個學習的過程當中,我仍是收穫蠻大的,即便現有框架不能知足部分功能,可是從新改造它代價若是比較高,也不建議,其二,學習的過程就是先原理,再接口,再註釋代碼的過程,就像前面的框架從一開始,我想實現的主要功能明白了,而後參考主要的原理,設計接口,最後寫代碼實現,豈有難載。java
第二個問題其實不只涉及到人與人,也涉及到了機器與人的關係,產品經理說,我想作一臺挖掘機來炒菜,挖掘機根據最好的優化路線行駛,就跟如今的無人車同樣,同時設備齊全,能根據主人的口味推薦出菜系,這樣既能夠保持其原有功用,又能夠做爲私家小助手,用最優雅的方式作出最美味的菜,不就是炒菜麼,對於不少人來講也不復雜,開個挖掘機相信也不須要太多知識,還有作推薦算法的,請一些相關領域專家,應該也不是很大問題,可是整個流程組合起來就比較費勁了,互聯網就是這樣,把生活中各類各類實實在在的問題用互聯網的思惟來實現,那麼有什麼問題呢,那就是溝通,各個專業人員之間的溝通,設計者的想法與實現者的想法的互動,機器與人的互動。聽起來這是個段子,或者科幻電影的情節,嗯,其實確實是。對於程序員,與同事的溝通,與產品經理溝通,需求是什麼,能實現成怎麼樣,就是看整個團隊的契合度吧。nginx
理解原理有用,但不要重複造輪子,不要重複造輪子,不要重複造輪子,寧願去github找一圈找到基本合適的輪子改造,也不要爲了裝逼寫本身輪子,不然會很難受,至於溝通,不得不說就是個難解,因此出來了面向接口設計,面向接口編程,這樣的方式比肥仔快樂水更天然。<div align="center"> <img src="http://p94g7wqy4.bkt.clouddn....; width="400"/> </div>
<div align="center"> <img src="http://p94g7wqy4.bkt.clouddn....; width="400"/> </div>
git
隨着先後端分離項目的熱潮,前端各大框架的,先後端溝通部分也成了問題,以前服務端渲染的頁面生成到前端來,如今先後端多是兩個服務器,一些技術的遷移,本框架的權限部分的設計思想,借鑑了前端大牛的想法,也有傳統後端的設計方案,拋磚引玉,作個橋樑,實現先後端分離的權限的設計,代碼僅供參考,思路僅供參考,相信優秀的你寫本身的代碼,用本身的思想會更爲貼切,方便。
最終即具備統一響應結構、 先後臺數據流起色制(HTTP消息與Java對象的互相轉化機制)、統一的異常處理機制、參數驗證機制、Cors跨域請求機制以及鑑權機制
前端設計:採用Vue的element ui ,對於前端設計者來講,應該很好理解源碼。
後端設計:shiro + ssm + redis存儲jwt
交互方式:前端存儲jwt,在訪問後端時攜帶,這也是惟一交互驗證方式。
前期工做:設計符合需求的vue模板,路由,資源,角色,用戶其中對應關係也可從數據表中體現出來程序員
實際的應用中,其一是要求用戶簡單地進行註冊登陸,其二是對其受權,附帶的有session管理和加密,因此誕生了shiro這款框架,而先後端分離的趨勢,使得shiro更好地應用於前端更有實際意義,而目前像vue相似的前端框架也很熱門,同時正好接觸到了vue,因此爲了適應要求,抽象出來基於先後端徹底分離的權限框架。
另外,通常認爲權限只能是後端來作,可是先後端分離的狀況下呢?這樣豈不是很沒有意義。何況關於vue的權限控制在業界相對沒有主流的方案,百度一下,這方面的資料也很少,基本都很零散。
前端地址:https://github.com/hulichao/z...
後端地址:https://github.com/hulichao/z...github
基本想法就是,用到Vuex 和 Vue Router 前者用來作狀態控制,後者綁定路由,這樣權限能夠直接對應到組件上,某個用於只能訪問某個組件,而不用將每一個組件都加上權限控制,重要的是還有單點登陸。
因此拋磚引玉,寫一個通用框架,(至少是通用想法)具體能夠模塊化來可插拔就ok 了。
非動態路由的問題是隻能在拿到權限以後初始化Vue實例,所以必須把登錄頁從SPA中剝離出來作成一個獨立的頁面,用戶登陸/退出操做須要在兩個url之間跳轉,體驗略差。redis
另外一種作法是直接用全部路由實例化應用,當用戶登陸拿到權限後再經過元素操做隱藏越權菜單,這時用戶還能夠手動輸入地址訪問越權頁面,所以還須要給路由加beforeEach鉤子來限制路由訪問,路由鉤子自己會增長必定的性能壓力,並且實例化即註冊全部路由也會使前端加載冗餘的路由組件。
本系統採用的在初始路由註冊首頁和登陸頁,並在拿到token後獲得權限,而後在實例化Vue實例。路由代碼以下:算法
const router = new Router({ routes: [ { path: '/login', name: "login", component: LoginView, meta: { requiresAuth: false } },{ path: '/index', redirect: '/', meta: { requiresAuth: true } } ] }); generateIndexRouter(); // 驗證token,存在才跳轉 router.beforeEach((to, from, next) => { let token = sessionStorage.getItem('token') if(to.path === '/') { if(!token) { next({ path: '/login', query: { redirect: to.fullPath } }) return } } if(to.meta.requiresAuth) { if(token) { next() } else { next({ path: '/login', query: { redirect: to.fullPath } }) } } else { next() } }); router.afterEach((to, from) => { // 設置麪包屑 let breadCrumbItems = [] let homePageCrumb = { title: '首頁', to: '/' } breadCrumbItems.push(homePageCrumb) if(to.meta.nameFullPath) { let fullPathSplit = to.meta.nameFullPath.split('/') fullPathSplit.forEach(( item, index ) => { let routerBreadCrumb = { title: item, to: (index == fullPathSplit.length - 1 ? to.path : '') } breadCrumbItems.push(routerBreadCrumb) }); } // 更新到state router.app.$store.dispatch('setBreadcurmbItems', breadCrumbItems) }) // 生成首頁路由 function generateIndexRouter() { if (!sessionStorage.routers) { return } let indexRouter = { path: "/", name: "/", component: resolve => require(['@/views/home/index'], resolve), children: [ ...generateChildRouters() ] } router.addRoutes([indexRouter]) } // 生成嵌套路由(子路由) function generateChildRouters() { let routers = JSON.parse(sessionStorage.routers) let childRouters = [] for(let router of routers) { if(router.code != null) { let routerProps = JSON.parse(router.properties) let childRouter = { path: router.url, name: router.code, component: resolve => require(['@/views/' + router.code + '/index'], resolve), meta: { routerId: router.id, requiresAuth: routerProps.meta.requiresAuth, nameFullPath: routerProps.nameFullPath } } childRouters.push(childRouter) } } return childRouters } export default router;
既然是restful風格,必然有通用返回狀態的類,遵循網上開源原則,一類繼承hashmap這樣達到能夠返回任意的數據,通用的數據就是code.msg.data這些,若是有分頁會另外加分頁,還有一種是,data.msg.state(code).token + 分頁類型的數據如:
"data": { "list": null, "pagebar": { "page": 1, "total": 2, "limit": 10 } }, "msg": "error", "state": 0, "is_redirect": true, "redirect_url": "http://qq.com", "token": null
本項目考慮到後期的擴展性,用到了第一類,其中實現了經常使用的失敗和成功的狀態碼及其響應,類名設計爲Result,位於zhcc-common下面,通常性地是封裝到ResponseEntity中返回。
分別對應http協議的get/put/post/delete方法,後端權限是:read/:update/:create/:delete
case "get": permissionString += ":read"; break; case "put": permissionString += ":update"; break; case "post": permissionString += ":create"; break; case "delete": permissionString += ":delete";
用的是com.baidu.unbiz.fluentvalidator.ValidationError 而不是hibernateValidator 減輕服務端編程等的壓力。直接在controller裏面驗證,最後封裝到Result的fail方法裏面返回。
權限的控制主要分爲4大類,主要是基於RBAC原理。
路由,資源,角色,用戶
路由級別和組件級別可控制
1.權限設計
2.異常設計
3.字典和其餘接口設計
4.先後的通信設計==
vue.js官網是最好的教程,vue.js官網是最好的教程,vue.js官網是最好的教程。不信的話,咱走着瞧!
一份 demo、一個入門指南、一個 API 列表,還有一個測試。
demo怎麼用
以爲不錯的話,賞唄咖啡唄,一杯不行半杯也能夠誒,若是進來fork一下下,star一下下再好不過啦。
說明一點,從學習自己來講並非難事,好比讀一本書,學會用一個框架,等等,即便零基礎到熟練,所花費的時間和精力也不會不少,而整個技能棧卻又是這樣一點一滴積累起來的,那些看起來洋洋得意的大神,背後都少不了"骯髒",爲何你就不能夠,由於你想速成,你想一晚上之間掌握全部的技能,因此如今的各類速成,好比21天學會從刪庫到跑路的書籍很流行,其實哪有捷徑,只有警記:自律能夠改變生活,成長在於堅持與積累。從刻意練習這裏能夠學到的是,學會學習,咱們做爲編程兒,不管哪一種形式要記得編程->反饋->修正->從新整理學習。更多的關注我的博客http://hulichao.top ,我這裏有酒,你要來麼?