跳到主要內容

大話設計,沒有模式—通用權限設計與實現

當代碼寫多了,總有些是經驗,但經驗是什麼呢?if…else用的次數比別人多?顯然不是。有些超棒的設計可以謂之經驗!


功能權限


網絡上流行的經典的權限設計是【主體】- 【領域】 - 【權限】( who、what、how問題原型 ) 的設計思想,其中:


【主體】可以是用戶,可以是角色,也可以是一個部門


【領域】可以是一個模塊,可以是一個頁面,也可以是頁面上的按鈕


【權限】可以是"可見",可以是"只讀",也可以是"可用"(如按鈕可以點擊)


為了簡化程序開發,在中去掉了權限的控制,簡化為【主體】- 【領域】的模式,且【主體】限定為角色。即只能給角色分配模塊和按鈕,不能直接分配給用戶賬號或部門。且一旦分配即表示該角色擁有操作該模塊(按鈕)的權限。



大道至簡,標準的RBAC規範比這個還要簡潔,所以它的生命力才最頑強。在此基礎上,如果進行二次開發,進行更詳細的功能權限控制,可以按照上面的思想進行改造。


數據權限


數據權限是在功能權限的基礎上面進一步的擴展,比如可以查看訂單屬於【功能權限】的範圍,但是可以查看哪些訂單就是【數據權限】的工作了。


這裏面的幾個概念:


【資源】:數據權限的控制對象,業務系統中的各種資源。比如訂單單據、銷售單等。


【數據規則】:用於數據權限的條件規則 。


應用場景



  • 銷售單,可以由本人查看

  • 銷售單,測試角色能看到自己的訂單

  • 銷售單,測試角色能看到自己的訂單,管理員角色可以看到所有訂單

  • 銷售單,測試角色能看到自己的訂單,管理員角色可以看到所有訂單,賬號test3可以看到應用名稱為"xxx管理系統"的訂單


我們能想到直接的方法,在訪問數據的入口加入SQL Where條件來實現,以上4種情況對應的sql語句:


  1 where CreateUserID = {loginUser} 
2 where CreateUserID = {loginUser} and {loginRole} in (測試)
3 where CreateUserID = ({loginUser} and {loginRole} in (測試)) or {loginRole} in (管理員)
4 where CreateUserID = ({loginUser} and {loginRole} in (測試)) or {loginRole} in (管理員) or ({loginUser}==test3 and 應用名稱==XXX管理系統)

這些一個一個的"條件",簡單理解為一個【數據規則】,通常會與原來我們前台的業務過濾條件合併再檢索出數據。


每一個角色有不一樣的【數據規則】,那麼數據權限設計就變成


  【資源】 - 【數據規則】


在數據庫記錄中存放為資源ID+規則的形式,如下:



為了簡化程序開發,在開發過程中可以做出以下約定:



  • 所有需要進行數據權限控制功能的表,在設計時必須包含字段CreateUserId(創建用戶Id)。

  • 【資源】的名稱限定為模塊名稱。如部門管理,用戶管理,那麼資源就是對應的部門列表,用戶列表。

  • 如果【資源】沒有設置數據規則,那麼視為該資源允許被任何主體查看。

  • 數據規則中授權的對象限定為角色、用戶。即不能設定為某個部門所有,如果想實現類似的功能,通過角色間接實現。例如:資源屬於角色"開發組成員","開發組組長"。


核心實現--查詢對象模式


權限控制總離不開一些條件的限制,如果沒有完善的查詢機制,那麼在做權限條件過濾的時候你會覺得很彆扭。馬丁在《企業應用架構模式》第13章對象-關係元數據映射模式中提出查詢對象模式(Query Object Pattern)。該模式核心結構如下:



該結構為【數據規則】的建立提供了理論基礎。在設計數據權限的時候,可以照搬該思想。上面例子中的規則,數據規則展開如下:


  1 { 
2 "Operation": "or",
3 "Filters": [{
4 "Key": "{loginRole}",
5 "Value": "09ee2ffa-7463-4938-ae0b-1cb4e80c7c13",
6 "Contrast": "contains",
7 "Text": "管理員"
8 }],
9 "Children": [{
10 "Operation": "and",
11 "Filters": [{
12 "Key": "{loginRole}",
13 "Value": "0a7ebd0c-78d6-4fbc-8fbe-6fc25c3a932d",
14 "Contrast": "contains",
15 "Text": "測試"
16 }, {
17 "Key": "CreateUserId",
18 "Value": "{loginUser}",
19 "Contrast": "==",
20 "Text": ""
21 }]
22 }, {
23 "Operation": "and",
24 "Filters": [{
25 "Key": "AppName",
26 "Value": "XXX管理平台",
27 "Contrast": "==",
28 "Text": ""
29 }, {
30 "Key": "{loginUser}",
31 "Value": "229f3a49-ab27-49ce-b383-9f10ca23a9d5,1df68dfd-3b6d-4491-872f-00a0fc6c5a64",
32 "Contrast": "in",
33 "Text": "test3,test4"
34 }]
35 }]
36 }

規則分為三個部分:【分組】(Children)、【規則】(Filter)、【操作符】(and or),而規則自身就是一個分組。這種簡單的結構就可以滿足全部的情況。看不懂啥意思?



這樣理解起來就比較簡單了。



還不懂??我們從簡單的開始:


某一角色只能看到自己創建的信息。如:針對資源列表,我們設置了【測試】角色可以看到自己創建的資源。



這時如果用一個擁有測試角色的賬號(test)登錄,那麼他只能看到自己創建的資源:



其他角色的賬號登錄時,會出現無法看到任何信息。我們稍做調整:【管理員】角色可以看到所有資源,【測試】角色只能看到自己創建的資源。



這時如果用一個擁有管理員角色的賬號(admin)登錄,那麼他就可以看到全部資源:



以此為基礎,我們可以擴展非常複雜的數據權限控制。最終形成最後的複雜規則:【管理員】角色可以看到所有資源,【測試】角色只能看到自己創建的資源。賬號test3/test4隻能看到應用名稱等於"XXX管理平台"的資源。


代碼解析--不要BB,秀出你的代碼


可以在應用層基類BaseApp中,定義一個通用函數,根據當前即將訪問的資源Id獲取相應的訪問【數據規則】,並把當前登錄的用戶信息注入到該規則中,最終轉換成針對數據庫的查詢,如下:(不想看這個?直接跳過吧,看看如何使用也沒有問題)


  1         protected IQueryable<T> GetDataPrivilege(string parametername) 
2 {
3 var loginUser = _auth.GetCurrentUser();
4 if (loginUser.User.Account == Define.SYSTEM_USERNAME) return UnitWork.Find<T>(null); //超級管理員特權
5
6 var moduleName = typeof(T).Name;
7 var rule = UnitWork.FindSingle<DataPrivilegeRule>(u => u.SourceCode == moduleName);
8 if (rule == null) return UnitWork.Find<T>(null); //沒有設置數據規則,那麼視為該資源允許被任何主體查看
9 if (rule.PrivilegeRules.Contains(Define.DATAPRIVILEGE_LOGINUSER) ||
10 rule.PrivilegeRules.Contains(Define.DATAPRIVILEGE_LOGINROLE))
11 {
12
13 //即把{loginUser} =='xxxxxxx'換為 loginUser.User.Id =='xxxxxxx',從而把當前登錄的用戶名與當時設計規則時選定的用戶id對比
14 rule.PrivilegeRules = rule.PrivilegeRules.Replace(Define.DATAPRIVILEGE_LOGINUSER, loginUser.User.Id);
15 var roles = loginUser.Roles.Select(u => u.Id).ToList();
16 roles.Sort(); //按字母排序,這樣可以進行like操作
17 rule.PrivilegeRules = rule.PrivilegeRules.Replace(Define.DATAPRIVILEGE_LOGINROLE,
18 string.Join(',',roles));
19 }
20 return UnitWork.Find<T>(null).GenerateFilter(parametername,
21 JsonHelper.Instance.Deserialize<FilterGroup>(rule.PrivilegeRules));
22 }

這樣在我們自己的應用中,使用上面的函數創建一個基礎查詢,再加上自定義的查詢條件即可輕鬆實現數據權限的控制。


  1             var result = new TableData(); 
2 var objs = GetDataPrivilege("u");
3 if (!string.IsNullOrEmpty(request.key))
4 {
5 objs = objs.Where(u => u.Id.Contains(request.key));
6 }
7
8 result.data = objs.OrderBy(u => u.Id)
9 .Skip((request.page - 1) * request.limit)
10 .Take(request.limit);

最後


以上所有代碼均已實現並開源(配置數據規則的界面可以自己畫,layui的前端畫起來實在太費力),秉承代碼之美,為.net core添磚加瓦,喜歡的star一下!


 


 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※高價收購3C產品,價格不怕你比較



※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!



網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!



3c收購,鏡頭 收購有可能以全新價回收嗎?



※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師"嚨底家"!!



Orignal From: 大話設計,沒有模式—通用權限設計與實現

留言

這個網誌中的熱門文章

Python 併發總結,多線程,多進程,異步IO

1 測量函數運行時間 import time def profile(func): def wrapper(*args, ** kwargs): import time start = time.time() func( *args, ** kwargs) end = time.time() print ' COST: {} ' .format(end - start) return wrapper @profile def fib(n): if n<= 2 : return 1 return fib(n-1) + fib(n-2 ) fib( 35 )   2 啟動多個線程,並等待完成   2.1 使用threading.enumerate() import threading for i in range(2 ): t = threading.Thread(target=fib, args=(35 ,)) t.start() main_thread = threading.currentThread() for t in threading.enumerate(): if t is main_thread: continue t.join()   2.2 先保存啟動的線程 threads = [] for i in range(5 ): t = Thread(target=foo, args= (i,)) threads.append(t) t.start() for t in threads: t.join()   3 使用信號量,限制同時能有幾個線程訪問臨界區 from threading import Semaphore import time sema = Semaphor...

高雄十大包子名店出爐

, 圖文:吳恩文 高雄包子大賽落幕了,我只能就我個人意見, 介紹一下前十名這些包子,但是不能代表其他四位評審的意見,雖然身為評審長,我通常不會第一個表示意見,以免影響其他評審, 我主要工作是負責發問。   這次參賽的素包子很少,而且都不夠細致,又偏油,我不愛, 但是第一名的甜芝麻包-熔岩黑金包,竟然是素食得名- 漢來蔬食巨蛋店。   這包子賣相太好,竹炭粉的黑色外皮刷上金粉,一上桌,眾人驚呼, 搶拍照,內餡是芝麻餡,混一點花生醬增稠,加入白糖芝麻油, 熔岩爆漿的程度剛剛好,我一直以為芝麻要配豬油才行、 但是選到好的黑芝麻油一樣不減香醇, 當下有二位評審就想宅配回家。   尤其特別的是,黑芝麻餡室溫易化,師傅必須要輪班躲在冷藏室內, 穿著大外套才能包,一天包不了多少,我笑說,漢來美食,集團餐廳那麼多,實力雄厚,根本是「 奧運選手報名參加村裡運動會」嘛,其他都是小包子店啊, 但是沒辦法,顯然大家都覺得它好看又好吃, 目前限定漢來蔬食高雄巨蛋店,二顆88元,可以冷凍宅配, 但是要排一陣子,因為供不應求,聽說,四月份, 台北sogo店開始會賣。   第二名的包子,左營寬來順早餐店,顯然平易近人的多,一顆肉包, 十塊錢,是所有參賽者中最便宜的,當然,個頭也小, 它的包子皮明顯和其他不同,灰灰的老麵,薄但紮實有嚼勁, 肉餡新鮮帶汁,因為打了些水,味道極其簡單,就是蔥薑,塩, 香油,薑味尤其明顯,是老眷村的味道, 而特別的是老闆娘是台灣本省人, 當年完全是依據眷村老兵的口味一步一步調整而來,沒有加什麼糖、 五香粉,胡椒粉,油蔥酥。就是蔥薑豬肉和老麵香,能得名, 應該是它的平實無華,鮮美簡單,打動人心。   這是標準的心靈美食,可以撫慰人心,得名之前,寛來順已經天天排隊,現在,恐怕要排更久了, 建議大家六七點早點上門。   第三名,「專十一」很神奇,我記得比賽最後, 大家連吃了幾家不能引起共鳴的包子,有些累,到了專十一, 就坐著等包子,其他評審一吃,就催我趕快試,我一吃, 也醒了大半。   它的包子皮厚薄適中,但是高筋麵粉高些,老麵加一點點酵母, 我心中,它的皮屬一屬二,至於餡又多又好吃,蛋黃還是切丁拌入, 不是整顆放,吃起來「美味、均衡、飽滿」。一顆二十元。   老闆是陸軍專科十一期畢業取名專十一,...

韋伯連續劇終於更新 期待第一季順利完結

  地球天文學界的跳票大王詹姆斯·韋伯空間望遠鏡 (James Webb Space Telescope,縮寫為 JWST)自 1996 年以來斷斷續續不按劇本演出的連續劇終於讓焦慮的觀眾們又等到了一次更新:五層遮陽罩測試順利完成。 裝配完成的韋伯望遠鏡與好夥伴遮陽罩同框啦。Credit: NASA   嚴格的測試是任何空間任務順利成功的重中之重。遮陽罩,這個韋伯望遠鏡異常重要的親密夥伴,要是無法正常運轉的話,韋伯的這一季天文界連續劇說不準就要一直拖更了。   詹姆斯·韋伯空間望遠鏡是歷史上造出的最先進的空間望遠鏡。它不僅是一架紅外望遠鏡,還具有特別高的靈敏度。但想要達到辣么高的靈敏度來研究系外行星和遙遠的宇宙童年,韋伯童鞋必須非常"冷靜",體溫升高的話,靈敏度會大大折損。這個時候,遮陽罩就要大顯身手啦。   遮陽罩在韋伯的設計中至關重要。韋伯望遠鏡會被發射到拉格朗日 L2 點,運行軌道很高,遠離太陽、地球與月球。太陽是韋伯的主要熱量干擾的來源,其次是地球與月球。遮陽罩會有效阻斷來自這三大熱源的能量並保護韋伯維持在工作溫度正常運轉。這個工作溫度指的是零下 220 攝氏度(-370 華氏度;50 開爾文)。 上圖中我們可以看出,韋伯望遠鏡的配置大致可分為兩部分:紅色較熱的一面溫度為 85 攝氏度,藍色較冷的一面溫度達到零下 233 攝氏度。紅色的這部分中,儀器包括太陽能板、通信設備、計算機、以及轉向裝置。藍色部分的主要裝置包括鏡面、探測器、濾光片等。Credit: STSci.   遮陽罩的那一部分和望遠鏡的鏡面這部分可以產生非常極端的溫差。遮陽的這面溫度可以達到 110 攝氏度,足以煮熟雞蛋,而背陰處的部分溫度極低,足以凍結氧氣。   工程師們剛剛完成了五層遮陽罩的測試,按照韋伯在 L2 時的運行狀態安裝了遮陽罩。L2 距離地球約 160 萬公里。NASA 表示這些測試使用了航天器的自帶系統來展開遮陽罩,測試目前都已成功完成。韋伯望遠鏡遮陽罩負責人 James Cooper 介紹說這是遮陽罩"第一次在望遠鏡系統的电子設備的控制下展開。儘管這個任務非常艱巨,難度高,但測試順利完成,遮陽罩展開時的狀態非常驚艷"。   遮陽罩由五層 Kapton 製成。Kapton 是一種聚酰亞胺薄膜材料, 耐高溫絕...