基於vue(element ui) + ssm + shiro 的許可權框架。
領悟,理解,消化它!
引言
心聲
現在的Java世界,各種資源很豐富,不得不說,從分散式,服務化,orm,再到前端控制,許可權等等玲琅滿目,網上有句話說,語言框架迭代太快了,我學不動了,不如回去搬磚吧,可是天這麼熱,磚燙手啊。程式搞起來很容易,就是有點頭冷。
<div align="center"> <img src="http://p94g7wqy4.bkt.clouddn....; width="400"/> </div>
程式設計師的兩大世界難題
重複輪子
語言框架迭代太快,沒錯,就簡單來說高階語言就有幾十種,雖然流行的就那麼幾種,語言就是重複之一,從語言想表達的作用上來看,都是為了操作計算機,我想未來計算機語言的前景可能是語言一體化,當然,這是個很漫長的路,相信一些語言的創造者,當初也是對某語言不滿意,然後就去改造,但是其實絕大部分還是重複的,這一方面,我深有體會,當初,僅僅為了更好地學習MVC框架原理,覺得最好的學習就是重寫它,最後,比如hulichao_framework下面的oliver就是結果的殘品,只是實現了基本的從頁面到處理端的對映,以及處理返回,其實想想也比較簡單,尤其是原理,就是頁面與控制器更好地處理與對映,當然完美重寫,我沒有這樣幹,現在流行的開源mvc框架已經很多了,另外一個就是簡單重構過orm框架hulichao_framework下面的yBatis,實現了什麼呢,就是資料庫與Java程式之間的相互對映,同時約定固定方法開頭的可以不需要寫sql語句,想說明什麼問題呢,其一,我在重複造輪子,當然在這個學習的過程中,我還是收穫蠻大的,即使現有框架不能滿足部分功能,但是重新改造它代價如果比較高,也不建議,其二,學習的過程就是先原理,再介面,再註釋程式碼的過程,就像前面的框架從一開始,我想實現的主要功能明白了,然後參考主要的原理,設計介面,最後寫程式碼實現,豈有難載。
溝通問題
第二個問題其實不僅涉及到人與人,也涉及到了機器與人的關係,產品經理說,我想做一臺挖掘機來炒菜,挖掘機根據最好的優化路線行駛,就跟現在的無人車一樣,同時裝置齊全,能根據主人的口味推薦出菜系,這樣既可以保持其原有功用,又可以作為私家小助手,用最優雅的方式做出最美味的菜,不就是炒菜麼,對於很多人來說也不復雜,開個挖掘機相信也不需要太多知識,還有做推薦演算法的,請一些相關領域專家,應該也不是很大問題,但是整個流程組合起來就比較費勁了,網際網路就是這樣,把生活中各種各種實實在在的問題用網際網路的思維來實現,那麼有什麼問題呢,那就是溝通,各個專業人員之間的溝通,設計者的想法與實現者的想法的互動,機器與人的互動。聽起來這是個段子,或者科幻電影的情節,嗯,其實確實是。對於程式設計師,與同事的溝通,與產品經理溝通,需求是什麼,能實現成怎麼樣,就是看整個團隊的契合度吧。
建議
理解原理有用,但不要重複造輪子,不要重複造輪子,不要重複造輪子,寧願去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>
正題
隨著前後端分離專案的熱潮,前端各大框架的,前後端溝通部分也成了問題,之前服務端渲染的頁面生成到前端來,現在前後端可能是兩個伺服器,一些技術的遷移,本框架的許可權部分的設計思想,借鑑了前端大牛的想法,也有傳統後端的設計方案,拋磚引玉,做個橋樑,實現前後端分離的許可權的設計,程式碼僅供參考,思路僅供參考,相信優秀的你寫自己的程式碼,用自己的思想會更為貼切,方便。
最終即具有統一響應結構、 前後臺資料流轉機制(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...
設計思路
基本想法就是,用到Vuex 和 Vue Router 前者用來做狀態控制,後者繫結路由,這樣許可權可以直接對應到元件上,某個用於只能訪問某個元件,而不用將每個元件都加上許可權控制,重要的是還有單點登入。
所以拋磚引玉,寫一個通用框架,(至少是通用想法)具體可以模組化來可插拔就ok 了。
非動態路由的問題是隻能在拿到許可權之後初始化Vue例項,因此必須把登陸頁從SPA中剝離出來做成一個獨立的頁面,使用者登入/退出操作需要在兩個url之間跳轉,體驗略差。
另一種做法是直接用所有路由例項化應用,當使用者登入拿到許可權後再通過元素操作隱藏越權選單,這時使用者還可以手動輸入地址訪問越權頁面,因此還需要給路由加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怎麼用
- git clone 前端地址 執行npm run dev 在這之前你可能需要按照一下npm 依賴的包,那就先執行npm init 然後 npm install, 最後再執行npm run dev或者npm run build 兩者的區別你懂的。
- git clone 後端地址 clone下來然後呢?修改資料庫路徑,執行sql匯入資料庫,最後執行於伺服器即可,當然這是開發階段,生產環境下的話,你可能需要nginx伺服器,來部署前端程式碼。
- 入門指南,對於這麼優秀的你,應該不需要了吧。
- API和測試後期再完善。請時刻關注本文件,獲取實時資訊。
捐贈(Donation)
覺得不錯的話,賞唄咖啡唄,一杯不行半杯也可以誒,如果進來fork一下下,star一下下再好不過啦。
參考
- 參考資料1:vue 許可權前端設計
- 參考資料2:csdn https://edu.csdn.net/course/p...
- 參考資料3:開源框架 https://gitee.com/zhocuhengli...
- 參考資料4:vue 官網
- 參考資料5:vue 許可權控制 https://github.com/OneWayTech...
刻意練習
說明一點,從學習本身來說並不是難事,比如讀一本書,學會用一個框架,等等,即使零基礎到熟練,所花費的時間和精力也不會很多,而整個技能棧卻又是這樣一點一滴積累起來的,那些看起來洋洋得意的大神,背後都少不了"骯髒",為什麼你就不可以,因為你想速成,你想一夜之間掌握所有的技能,所以現在的各種速成,比如21天學會從刪庫到跑路的書籍很流行,其實哪有捷徑,只有警記:自律可以改變生活,成長在於堅持與積累。從刻意練習這裡可以學到的是,學會學習,我們作為程式設計兒,無論哪種形式要記得程式設計->反饋->修正->重新整理學習。更多的關注個人部落格http://hulichao.top ,我這裡有酒,你要來麼?