寫(xiě)在開(kāi)始的話--好像叫前言吧

　　總算找到時(shí)間總結(jié)一下現(xiàn)在對(duì)于權(quán)限系統(tǒng)的思考了, 今天天氣不錯(cuò), 適合發(fā)白日夢(mèng)和寫(xiě)博客. 既然是寫(xiě)在前面的話, 那么有幾點(diǎn)是必須要說(shuō)明的. 下面的想法可能會(huì)非常奇葩, 會(huì)給人一種生搬硬套 +?走投無(wú)路的感覺(jué). 希望不小心看到的不要被這種想法折磨就好了. 然后, 這篇文章嘛, 其實(shí)很大的一部分是為了自己的思路做整理. 所以如果有時(shí)跳躍太犀利的話, 就當(dāng)沒(méi)看見(jiàn)吧~?

---

方案1--字符串標(biāo)識(shí)法:?

　　原理: 用戶 - 功能點(diǎn).

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

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

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

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

---

?

方案2--角色法:

　　原理: 用戶 - 角色 - 功能點(diǎn)

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

　　方法: 這里不玩字符串了, 直接上數(shù)據(jù)表. 權(quán)限表(pk: 權(quán)限ID), 用戶表(pk: 用戶ID), 角色表(pk: 角色I(xiàn)D), 角色-權(quán)限表(pk:角色I(xiàn)D + 權(quán)限ID), 用戶-角色表(pk: 用戶ID-角色I(xiàn)D). 總的來(lái)說(shuō)是三張成員表和兩張關(guān)系表. 也沒(méi)什么技術(shù)含量了, 各個(gè)對(duì)號(hào)入座即可. 因?yàn)橐粋€(gè)基于不靠譜理論產(chǎn)生的不靠譜方法(至少我這么認(rèn)為), 因此我就不累贅了, 拓展吧.

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

　　總結(jié): 這個(gè)模型其實(shí)并不復(fù)雜, 但是他對(duì)于特權(quán)問(wèn)題不能很好的解決. 不過(guò)這個(gè)模型還是有其優(yōu)點(diǎn). 最大的優(yōu)點(diǎn)就是實(shí)現(xiàn)起身非常簡(jiǎn)單, 起碼符合大眾邏輯. 使用它能滿足大部分需求, 對(duì)于不能滿足的需求, 它也能做到很好的讓步和妥協(xié). 缺點(diǎn)嘛~ 當(dāng)然是有的, 例如每次用戶操作的時(shí)候都必須訪問(wèn)一次數(shù)據(jù)庫(kù), 但是這個(gè)屬于技術(shù)上問(wèn)題, 可以通過(guò)技術(shù)解決. 比如本地讀, 遠(yuǎn)端或者用一些持久化的框架也可以很好的解決這個(gè)問(wèn)題. 但就整體而言, 這個(gè)模型還是非常適合大中小學(xué)生使用的.

---

?

方案3--逆向思維:

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

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

　　理 & 論: 上面說(shuō)了很多用戶對(duì)應(yīng)功能點(diǎn)了. 那么功能點(diǎn)對(duì)用戶來(lái)說(shuō)是怎樣的呢? 其實(shí)謎底已經(jīng)在黑幫大佬的那句話里面了~ 因?yàn)槲覀冇懻摰亩际腔谟脩裟茏鍪裁? 而沒(méi)有規(guī)定用戶不能做什么. 而通過(guò)角色來(lái)管理用戶權(quán)限實(shí)際上是一種粗放式的解決方案. 而如何在這基礎(chǔ)上細(xì)化(比如允許某用戶能做一些角色外的事情, 或者不允許用戶做一些角色內(nèi)的事情), 這樣就需要為每個(gè)功能點(diǎn)定義用戶的訪問(wèn)權(quán)限了. 并且在這里定義的權(quán)限粒度更細(xì), 權(quán)力更高(相對(duì)角色定義的權(quán)限而言).

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

?

?

---

總結(jié)--并不完美的結(jié)局:

　　這里探討了權(quán)限的模型, 基本依據(jù)嘛. 是沒(méi)有的~ 但是作為一個(gè)用了win系統(tǒng)這么多年的人, 有想法是必然的. 方案一有人跟我說(shuō)是Linux的權(quán)限設(shè)計(jì)就是這樣~ 我也沒(méi)有做過(guò)調(diào)查, 也不知道他所說(shuō)的是哪個(gè)版本的權(quán)限設(shè)計(jì), 但就這樣吧, 畢竟這是一個(gè)很好的思路和切入點(diǎn). 重點(diǎn)是, 對(duì)比三個(gè)方案, 我更喜歡方案一.?

　　之所以說(shuō)并不完美的結(jié)局, 是因?yàn)檫@個(gè)模型肯定并不是最好的, 最全的. 就我想到的很多地方也沒(méi)有涉及討論到~ 比如, 用戶權(quán)限的繼承性(比如A是B和C的一個(gè)上級(jí)那么A一般是繼承了B和C的權(quán)限), 權(quán)限的等級(jí)劃分(功能點(diǎn)的粒度), 角色管理的拓展(比如有組啊, Department啊的概念)等等等等.?

　　不過(guò)正因如此, 正因?yàn)槟Ｐ偷牟煌昝? 程序才會(huì)有bug, 而又正因?yàn)檫@些bug, 程序員才有飯食, 因此BUG是美好的, 不完美是賽高的~

?

-----GSSL -----

---

?

2014-03-18

后記--反思:

　　剛才基于上面的考慮, 去跟度娘交流了一下, 發(fā)現(xiàn)了一個(gè)名詞叫"RBAC", 具體參閱下面的鏈接:?

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

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

　　最后大家反映口語(yǔ)化比較嚴(yán)重, 其實(shí)嘛, 作為一個(gè)一天到晚也不怎么寫(xiě)公文老想著寫(xiě)小說(shuō)的人來(lái)說(shuō), 也就這點(diǎn)水平了. 往后會(huì)注意注意, 大家見(jiàn)諒見(jiàn)諒~~

?

-----GSSL -----

轉(zhuǎn)載于:https://www.cnblogs.com/gssl/p/3601110.html

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。