寫在開始的話--好像叫前言吧

　　總算找到時間總結一下現在對于權限系統的思考了, 今天天氣不錯, 適合發白日夢和寫博客. 既然是寫在前面的話, 那么有幾點是必須要說明的. 下面的想法可能會非常奇葩, 會給人一種生搬硬套 +?走投無路的感覺. 希望不小心看到的不要被這種想法折磨就好了. 然后, 這篇文章嘛, 其實很大的一部分是為了自己的思路做整理. 所以如果有時跳躍太犀利的話, 就當沒看見吧~?

---

方案1--字符串標識法:?

　　原理: 用戶 - 功能點.

　　理 & 論: 這個是比較簡單, 但是給我的感覺又是最觸及核心(我喜歡"觸及核心"和"貼近本質"這兩個詞). 為什么這么說呢? 因為所謂權限, 從感性上來說就是一句話:(請用黑社會老大教訓黑社會小弟的語氣) 有些事情~你能干, 但是有些事情~~~你不能! 好吧, 那么簡單來說呢, 所謂權限就是高中的一句英語句型: someone can do sth. 那么就是翻譯成程序語言就是: 用戶, 能做xx事情. 那么基于這句話的建模就是: 系統 == 功能點的集合. 在這上面, 我們不需要設計模式, 不需要模塊化, 什么都不需要, 很純, 很干凈, 很傻, 很天真. 但是, 這是我覺得這里是最貼近本質的部分. 這里是赤子之心, 這里是返璞歸真. 這里是起點, 這里是終點.

　　方法: 好吧, 其實這個也是被廣泛用到的方法了. 首先這個理論是某人能做某事, 那么某事對于某人來說只有兩種狀態: 能做 / 不能做. 如果用數字來表示, 我推薦1 / 0, ?當然不排除某些奇葩喜歡用2/3, 4/5. 好吧~ 如果事成了記得寫篇論文(內心的奇葩一巴掌過來, miss). 然后我推薦用二進制表示, 比如第一個功能點是第一位, 第二個功能點是第二位, 如此類推, 在定義功能點的時候我們可以用 funcFlag = 1 << n. 來為每個功能點設標記. 然后配置用戶權限的時候只需要把各個功能點的標識用 | , | 起來就好了(話說這個 | 應該叫異或). 然后每個用戶都有一個二進制數, 然后這個二進制數就代表了這個用戶具有哪些權限了.

　　拓展1: 好吧, 上面的方法目測是很美好, 實際上也很美好, 如果我的系統足夠小(小于32個或64個功能點), 或者計算機硬/軟件技術發展的足夠犀利(intN,從硬件和軟件的角度成立), 那么只用上面的技術配套完善的文檔(主要是funFlag -- 功能描述), 其實是足夠的了~ 那么如何解決int型存儲的不足呢? 這個問題跟在學校的時候遇到的一個超大數相加的問題有點眉來眼去的感覺了~ 事實上還是有點區別的, 這里的解法(非標準, 是我的一個朋友給出的)是把二進制數壓縮成16進制數, 然后用字符串存起來. 文檔里面寫明字符串的第n位包含哪些功能即可. 那么, 系統對于每個用戶的權限都可以用一條字符串來描述了~(當然還有必不可少的文檔啦~)

　　總結: 好了, 方法1其實是我比較鐘愛的, 但由于數位問題, 他一般是在一些固定個數的配置項中用到--定義幾個常量, 然后相 | 就解決問題了. 然后實際上會用到實際來解決權限問題的方法是拓展1提到的. 跟我提出這個想法的朋友說這個方法很復雜(?) 建議我不要用. 而我的看法是, 這個辦法其實是很不錯的. 說實現嘛, 其實只要是個智力正常, 不帶坑的程序員, 是能實現的. 而這個方法最大的問題在于維護成本. 具體表現在, 配置一個用戶權限的時候, 必須細化到每個功能點去配置. 代碼維護的難度和可讀性也不強(這點是我朋友提出的, 我對此是抱觀望態度的~)

---

?

方案2--角色法:

　　原理: 用戶 - 角色 - 功能點

　　理 & 論: 終于來到這個我一開始就想到的模型了(上面方案一是我在想:究竟能不能簡單點啊?的時候想到的, 結果發現原來大家都想到了:( ). 這個模型就是把功能點納入角色, 然后用戶只要分配不同的角色就能擁有相應的功能點的(我自己敲出來都覺得啰嗦~). 這個理論相對簡單(跟方法一比簡直戰斗力只有五啊~), 但是有幾點是值得注意的, 比如: 我有一個用戶屬于整個群體的異類, 他擁有某些角色外的功能點, 這里有一個詞比較好形容--特權(我就喜歡中華文化的博大精深). 對于這部分異類應該如何處理呢. 這是個謎. 因此這個原理要求用戶是沒有特權的 => 這樣要求分工的邊界需要非常明確(這個情況可能只會出現在理想鄉~).

　　方法: 這里不玩字符串了, 直接上數據表. 權限表(pk: 權限ID), 用戶表(pk: 用戶ID), 角色表(pk: 角色ID), 角色-權限表(pk:角色ID + 權限ID), 用戶-角色表(pk: 用戶ID-角色ID). 總的來說是三張成員表和兩張關系表. 也沒什么技術含量了, 各個對號入座即可. 因為一個基于不靠譜理論產生的不靠譜方法(至少我這么認為), 因此我就不累贅了, 拓展吧.

　　拓展: 好的, 你以為這里會有什么高深的理論嗎? 太天真了~ 在這個框架下如何解決特權問題呢? 這樣的話只需要再建立一個特權的角色即可~ 什么? 你說萬一有特權的角色很多導致間接性為每個用戶都創建了一個特權的角色到頭來還是走了方案一的路子? 如果我說這個模型其實只是一個簡單的開模型(這個是我發明的詞, 意思就是此模型只定義了你能干什么, 而沒有定義你不能干什么~), 它并不能滿足現實復雜的狀況的話估計看到這里的人就會抽死我了吧. 抽死我吧!

　　總結: 這個模型其實并不復雜, 但是他對于特權問題不能很好的解決. 不過這個模型還是有其優點. 最大的優點就是實現起身非常簡單, 起碼符合大眾邏輯. 使用它能滿足大部分需求, 對于不能滿足的需求, 它也能做到很好的讓步和妥協. 缺點嘛~ 當然是有的, 例如每次用戶操作的時候都必須訪問一次數據庫, 但是這個屬于技術上問題, 可以通過技術解決. 比如本地讀, 遠端或者用一些持久化的框架也可以很好的解決這個問題. 但就整體而言, 這個模型還是非常適合大中小學生使用的.

---

?

方案3--逆向思維:

　　總結: 不要驚訝, 就是對上面兩個方案的總結, 這樣才能推理出我為什么能想到這一步. 首先, 針對方案一和方案二找共同點(他們兩個模型你說有什么共同點呢?). 然后倒轉這些共同點. 答案可能就在里面. 思考........................................好的, 也不知道想到沒有, 或者說有沒有想. 他們兩個的共同點其實很明顯, 就是都是基于用戶作考慮的. 但是我們到底有沒有考慮過功能點的心情呢? (啊~ 好像愛情肥皂劇). 因此為了解決特權問題, 我們需要重新考慮一下功能點的心情了~

　　原理: (用戶 - 角色 - 功能點) + (功能點 - 用戶)

　　理 & 論: 上面說了很多用戶對應功能點了. 那么功能點對用戶來說是怎樣的呢? 其實謎底已經在黑幫大佬的那句話里面了~ 因為我們討論的都是基于用戶能做什么, 而沒有規定用戶不能做什么. 而通過角色來管理用戶權限實際上是一種粗放式的解決方案. 而如何在這基礎上細化(比如允許某用戶能做一些角色外的事情, 或者不允許用戶做一些角色內的事情), 這樣就需要為每個功能點定義用戶的訪問權限了. 并且在這里定義的權限粒度更細, 權力更高(相對角色定義的權限而言).

　　方法: 在方案二方法里面的5張表的基礎上再加一張 權限-用戶表(pk: 權限ID + 用戶ID), 變成三張成員表和三張關系表. 并且權限點-用戶表里面定義的權限是覆蓋角色-權限表, 這樣一個比較符合實際情況的模型就出來了.

?

?

---

總結--并不完美的結局:

　　這里探討了權限的模型, 基本依據嘛. 是沒有的~ 但是作為一個用了win系統這么多年的人, 有想法是必然的. 方案一有人跟我說是Linux的權限設計就是這樣~ 我也沒有做過調查, 也不知道他所說的是哪個版本的權限設計, 但就這樣吧, 畢竟這是一個很好的思路和切入點. 重點是, 對比三個方案, 我更喜歡方案一.?

　　之所以說并不完美的結局, 是因為這個模型肯定并不是最好的, 最全的. 就我想到的很多地方也沒有涉及討論到~ 比如, 用戶權限的繼承性(比如A是B和C的一個上級那么A一般是繼承了B和C的權限), 權限的等級劃分(功能點的粒度), 角色管理的拓展(比如有組啊, Department啊的概念)等等等等.?

　　不過正因如此, 正因為模型的不完美, 程序才會有bug, 而又正因為這些bug, 程序員才有飯食, 因此BUG是美好的, 不完美是賽高的~

?

-----GSSL -----

---

?

2014-03-18

后記--反思:

　　剛才基于上面的考慮, 去跟度娘交流了一下, 發現了一個名詞叫"RBAC", 具體參閱下面的鏈接:?

http://baike.baidu.com/link?url=ORrqMuCuxuSeiCFBDJNTPMb5pDZco1Lc9qFqMJrDFlf4QZlYRU89zXWZhkeqkkGF

　　而方案二我思考之后認為是這個模型的原型. 而方案三是一個變種, 度娘還告訴了我們其他的變種, 比如RBAC96模型, ARABC97模型, DRABC等. 其中涉及了授權認證(對賦予權限的一方進行分離), 角色分級, 等等的新的概念, 其實這里的目的也只不過是拋磚引玉. 因為權限系統是非常龐大的一項工程. 其中涉及的領域也是十分之多, 就我所見除了基礎的碼農之外(也就是程序猿啦), 會有信息安全領域, 計算機網絡, 應用數學, 管理學等等的人參與才能實現和完善. 因此一人之力甚微, 遇到的問題肯定會很多. 而值得安慰的是: 就算別人家好幾百人來做的這個系統, 到頭來還是會遇到問題, 還是需要不斷的Debug(而且他們遇到的問題肯定比小系統多, 因此需要更加多的人手, 然后產生更加多的問題, 然后....). 因此得出一個非常離題的結論是: 小系統養家糊口, 大系統養家s糊口s.?

　　最后大家反映口語化比較嚴重, 其實嘛, 作為一個一天到晚也不怎么寫公文老想著寫小說的人來說, 也就這點水平了. 往后會注意注意, 大家見諒見諒~~

?

-----GSSL -----

轉載于:https://www.cnblogs.com/gssl/p/3601110.html

總結

以上是生活随笔為你收集整理的关于权限系统的一些思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。