跳到主要內容

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

當代碼寫多了,總有些是經驗,但經驗是什麼呢?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...

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

  地球天文學界的跳票大王詹姆斯·韋伯空間望遠鏡 (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 是一種聚酰亞胺薄膜材料, 耐高溫絕...

LINE 發票管家「一鍵分享發票」新功能,聚餐AA更好算帳

» » LINE 發票管家「一鍵分享發票」新功能,聚餐AA更好算帳 消費明細好清楚,不怕算錯錢啦! by in , 讀取中... 之前介紹過的「LINE 發票管家」,除了能對統一發票、管理消費紀錄,現在還能分享消費明細給其他朋友囉!趕快來看看該如何分享吧!讓大家在聚餐過後,不用再截圖、拍照把消費明細記錄下來分享到 LINE 好友群組,只要用 LINE發票管家就可以隨時一鍵分享消費明細,包括店家、消費時間、消費項目、金額通通都有,聚餐 AA 也更好算帳。 LINE 發票管家「一鍵分享發票」新功能,聚餐AA更好算帳 朋友聚餐完,經常會先由其中一位買單再事後收帳,不過難免擔心忘記拍照紀錄下消費明細,導致算帳變得很麻煩。但是,現在只要用 LINE發票管家,不僅能將發票存入載具後直接匯入發票,進而更方便管理每月的消費情況,現在還能用它來分享消費明細到 LINE 聊天室,不需要截圖,整個流程超級簡單! ▲圖片來源: 當使用 LINE發票管家並且綁定載具後,只要日常消費有將發票存入載具就通通會自動匯入 LINE發票管家。如果想暸解自己近期的消費情況,也能在 LINE發票管家點選「發票明細」查詢所有消費紀錄。 *小提醒:存入手機條碼的發票,待財政部 1-2 日作業時間將發票資料匯入後, 打開單筆消費後分享到指定對象或群組。 像是朋友聚餐或其它購物消費,就能在 LINE發票管家查看每一筆消費的所有消費明細,每一項餐點的項目、價格通通一目了然。如果想將該筆消費內容分享給好友收帳,只要點選該筆消費明細後,接著點選畫面右上角的「分享」按鈕。 網頁設計 最專業,超強功能平台可客製,窩窩以「數位行銷」「品牌經營」「網站與應用程式」「印刷品設計」等四大主軸,為每一位客戶客製建立行銷脈絡及洞燭市場先機,請問 台中電動車 哪裡在賣比較便宜可以到台中景泰電動車門市去看看總店:臺中市潭子區潭秀里雅潭路一段102-1號。 電動車補助 推薦評價好的 iphone維修 中心擁有專業的維修技術團隊,同時聘請資深iphone手機維修專家,現場說明手機問題,快速修理,沒修好不收錢住家的頂樓裝 太陽光電 聽說可發揮隔熱功效一線推薦東陽能源擁有核心技術、...