系统权限管理设计 （转）
權(quán)限設(shè)計(jì)（初稿）???
? 1. 前言：???
? 權(quán)限管理往往是一個(gè)極其復(fù)雜的問題，但也可簡單表述為這樣的邏輯表達(dá)式：判斷“Who對(duì)What(Which)進(jìn)行How的操作”的邏輯表達(dá)式是否為真。針對(duì)不同的應(yīng)用，需要根據(jù)項(xiàng)目的實(shí)際情況和具體架構(gòu)，在維護(hù)性、靈活性、完整性等N多個(gè)方案之間比較權(quán)衡，選擇符合的方案。???
? 2. 目標(biāo)：???
? 直觀，因?yàn)橄到y(tǒng)最終會(huì)由最終用戶來維護(hù)，權(quán)限分配的直觀和容易理解，顯得比較重要簡單，包括概念數(shù)量上的簡單和意義上的簡單還有功能上的簡單。想用一個(gè)權(quán)限系統(tǒng)解決所有的權(quán)限問題是不現(xiàn)實(shí)的。設(shè)計(jì)中將常常變化的“定制”特點(diǎn)比較強(qiáng)的部分判斷為業(yè)務(wù)邏輯，而將常常相同的“通用”特點(diǎn)比較強(qiáng)的部分判斷為權(quán)限邏輯就是基于這樣的思路。???
? 3. 現(xiàn)狀：???
? 對(duì)于在企業(yè)環(huán)境中的訪問控制方法，一般有三種：???
? 1.自主型訪問控制方法：目前在我國的大多數(shù)的信息系統(tǒng)中的訪問控制模塊中基本是借助于自主型訪問控制方法中的訪問控制列表(ACLs)。???
? 2.強(qiáng)制型訪問控制方法：用于多層次安全級(jí)別的軍事應(yīng)用。???
? 3.基于角色的訪問控制方法（RBAC）：是目前公認(rèn)的解決大型企業(yè)的統(tǒng)一資源訪問控制的有效方法。其顯著的兩大特征是：1.減小授權(quán)管理的復(fù)雜性，降低管理開銷。2.靈活地支持企業(yè)的安全策略，并對(duì)企業(yè)的變化有很大的伸縮性。???
? 4. 名詞：???
? 粗粒度：表示類別級(jí)，即僅考慮對(duì)象的類別(the?? type?? of?? object)，不考慮對(duì)象的某個(gè)特定實(shí)例。比如，用戶管理中，創(chuàng)建、刪除，對(duì)所有的用戶都一視同仁，并不區(qū)分操作的具體對(duì)象實(shí)例。???
? 細(xì)粒度：表示實(shí)例級(jí)，即需要考慮具體對(duì)象的實(shí)例(the?? instance?? of?? object)，當(dāng)然，細(xì)粒度是在考慮粗粒度的對(duì)象類別之后才再考慮特定實(shí)例。比如，合同管理中，列表、刪除，需要區(qū)分該合同實(shí)例是否為當(dāng)前用戶所創(chuàng)建。???
? 5. 原則：???
? 權(quán)限邏輯配合業(yè)務(wù)邏輯。即權(quán)限系統(tǒng)以為業(yè)務(wù)邏輯提供服務(wù)為目標(biāo)。相當(dāng)多細(xì)粒度的權(quán)限問題因其極其獨(dú)特而不具通用意義，它們也能被理解為是“業(yè)務(wù)邏輯”的一部分。比如，要求：“合同資源只能被它的創(chuàng)建者刪除，與創(chuàng)建者同組的用戶可以修改，所有的用戶能夠?yàn)g覽”。這既可以認(rèn)為是一個(gè)細(xì)粒度的權(quán)限問題，也可以認(rèn)為是一個(gè)業(yè)務(wù)邏輯問題。在這里它是業(yè)務(wù)邏輯問題，在整個(gè)權(quán)限系統(tǒng)的架構(gòu)設(shè)計(jì)之中不予過多考慮。當(dāng)然，權(quán)限系統(tǒng)的架構(gòu)也必須要能支持這樣的控制判斷。或者說，系統(tǒng)提供足夠多但不是完全的控制能力。即，設(shè)計(jì)原則歸結(jié)為：“系統(tǒng)只提供粗粒度的權(quán)限，細(xì)粒度的權(quán)限被認(rèn)為是業(yè)務(wù)邏輯的職責(zé)”。???
? 權(quán)限公式：Who+What(Which)+How?? 的問題，在這里我們實(shí)現(xiàn)What和部分Which的權(quán)限問題(粗粒度和細(xì)粒度相合，到一定的程度)，其他的權(quán)限問題留給業(yè)務(wù)邏輯解決???
? 6. 概念：???
? Who：權(quán)限的擁用者或主體（Principal(負(fù)責(zé)人)、User、Group、Role、Actor等等）???
? What：權(quán)限針對(duì)的對(duì)象或資源（Resource、Class）。???
? How：具體的權(quán)限（Privilege,?? 正向授權(quán)與負(fù)向授權(quán)）。???
? Role：是角色，擁有一定數(shù)量的權(quán)限。???
? Operator：操作。表明對(duì)What的How?? 操作。???
? 7. 解釋：???
? User：與?? Role?? 相關(guān)，用戶僅僅是純粹的用戶，權(quán)限是被分離出去了的。User是不能與?? Privilege?? 直接相關(guān)的，User?? 要擁有對(duì)某種資源的權(quán)限，必須通過Role去關(guān)聯(lián)。解決?? Who?? 的問題。???
? Resource：就是系統(tǒng)的資源，比如部門新聞，文檔等各種可以被提供給用戶訪問的對(duì)象。???
? Privilege：是Resource?? Related的權(quán)限。就是指，這個(gè)權(quán)限是綁定在特定的資源實(shí)例上的。比如說部門新聞的發(fā)布權(quán)限，叫做"部門新聞發(fā)布權(quán)限"。這就表明，該P(yáng)rivilege是一個(gè)發(fā)布權(quán)限，而且是針對(duì)部門新聞這種資源的一種發(fā)布權(quán)限。Privilege是由Creator在做開發(fā)時(shí)就確定的。Privilege?? 如"刪除"?? 是一個(gè)抽象的名詞，當(dāng)它不與任何具體的?? Object?? 或?? Resource?? 綁定在一起時(shí)是沒有任何意義的。拿新聞發(fā)布來說，發(fā)布是一種權(quán)限，但是只說發(fā)布它是毫無意義的。因?yàn)椴恢腊l(fā)布可以操作的對(duì)象是什么。只有當(dāng)發(fā)布與新聞結(jié)合在一起時(shí)，才會(huì)產(chǎn)生真正的?? Privilege。這就是?? Privilege?? Instance。???
? Role：是粗粒度和細(xì)粒度(業(yè)務(wù)邏輯)的接口，一個(gè)基于粗粒度控制的權(quán)限框架軟件，對(duì)外的接口應(yīng)該是Role，具體業(yè)務(wù)實(shí)現(xiàn)可以直接繼承或拓展豐富Role的內(nèi)容，Role不是如同User或Group的具體實(shí)體，它是接口概念，抽象的通稱。???
? Operator的定義包括了Resource?? Type和Method概念。即，What和How的概念。之所以將What和How綁定在一起作為一個(gè)Operator概念而不是分開建模再建立關(guān)聯(lián)，這是因?yàn)楹芏嗟腍ow對(duì)于某What才有意義。比如，發(fā)布操作對(duì)新聞對(duì)象才有意義，對(duì)用戶對(duì)象則沒有意義。???
? 8. 思想：???
? 權(quán)限系統(tǒng)的核心由以下三部分構(gòu)成：1.創(chuàng)造權(quán)限，2.分配權(quán)限，3.使用權(quán)限，然后，系統(tǒng)各部分的主要參與者對(duì)照如下：1.創(chuàng)造權(quán)限?? -?? Creator創(chuàng)造，2.分配權(quán)限?? -?? Administrator?? 分配，3.使用權(quán)限?? -?? User：???
? 1.?? Creator?? 創(chuàng)造?? Privilege，?? Creator?? 在設(shè)計(jì)和實(shí)現(xiàn)系統(tǒng)時(shí)會(huì)劃分，一個(gè)子系統(tǒng)或稱為模塊，應(yīng)該有哪些權(quán)限。這里完成的是?? Privilege?? 與?? Resource?? 的對(duì)象聲明，并沒有真正將?? Privilege?? 與具體Resource?? 實(shí)例聯(lián)系在一起，形成Operator。???
? 2.?? Administrator?? 指定?? Privilege?? 與?? Resource?? Instance?? 的關(guān)聯(lián)。在這一步，?? 權(quán)限真正與資源實(shí)例聯(lián)系到了一起，?? 產(chǎn)生了Operator（Privilege?? Instance）。Administrator利用Operator這個(gè)基本元素，來創(chuàng)造他理想中的權(quán)限模型。如，創(chuàng)建角色，創(chuàng)建用戶組，給用戶組分配用戶，將用戶組與角色關(guān)聯(lián)等等...這些操作都是由?? Administrator?? 來完成的。???
? 3.?? User?? 使用?? Administrator?? 分配給的權(quán)限去使用各個(gè)子系統(tǒng)。Administrator?? 是用戶，在他的心目中有一個(gè)比較適合他管理和維護(hù)的權(quán)限模型。于是，程序員只要回答一個(gè)問題，就是什么權(quán)限可以訪問什么資源，也就是前面說的?? Operator。程序員提供?? Operator?? 就意味著給系統(tǒng)穿上了盔甲。Administrator?? 就可以按照他的意愿來建立他所希望的權(quán)限框架可以自行增加，刪除，管理Resource和Privilege之間關(guān)系。可以自行設(shè)定用戶User和角色Role的對(duì)應(yīng)關(guān)系。(如果將?? Creator看作是?? Basic?? 的發(fā)明者，?? Administrator?? 就是?? Basic?? 的使用者，他可以做一些腳本式的編程)?? Operator是這個(gè)系統(tǒng)中最關(guān)鍵的部分，它是一個(gè)紐帶，一個(gè)系在Programmer，Administrator，User之間的紐帶。
但凡涉及多用戶不同權(quán)限的網(wǎng)絡(luò)或者單機(jī)程序，都會(huì)有權(quán)限管理的問題，比較突出的是MIS系統(tǒng)。 ? ??
? ??
? 下面我要說的是MIS系統(tǒng)權(quán)限管理的數(shù)據(jù)庫設(shè)計(jì)及實(shí)現(xiàn)，當(dāng)然，這些思路也可以推廣開來應(yīng)用，比如說在BBS中用來管理不同級(jí)別的用戶權(quán)限。 ? ??
? ??
? 權(quán)限設(shè)計(jì)通常包括數(shù)據(jù)庫設(shè)計(jì)、應(yīng)用程序接口(API)設(shè)計(jì)、程序?qū)崿F(xiàn)三個(gè)部分。 ? ??
? ??
? 這三個(gè)部分相互依存，密不可分，要實(shí)現(xiàn)完善的權(quán)限管理體系，必須考慮到每一個(gè)環(huán)節(jié)可行性與復(fù)雜程度甚至執(zhí)行效率。 ? ??
? ??
? 我們將權(quán)限分類，首先是針對(duì)數(shù)據(jù)存取的權(quán)限，通常有錄入、瀏覽、修改、刪除四種，其次是功能，它可以包括例如統(tǒng)計(jì)等所有非直接數(shù)據(jù)存取操作，另外，我們還可能對(duì)一些關(guān)鍵數(shù)據(jù)表某些字段的存取進(jìn)行限制。除此，我想不出還有另外種類的權(quán)限類別。 ? ??
? ??
? 完善的權(quán)限設(shè)計(jì)應(yīng)該具有充分的可擴(kuò)展性，也就是說，系統(tǒng)增加了新的其它功能不應(yīng)該對(duì)整個(gè)權(quán)限管理體系帶來較大的變化，要達(dá)到這個(gè)目的，首先是數(shù)據(jù)庫設(shè)計(jì)合理，其次是應(yīng)用程序接口規(guī)范。 ? ??
? ??
? 我們先討論數(shù)據(jù)庫設(shè)計(jì)。通常我們使用關(guān)系數(shù)據(jù)庫，這里不討論基于Lotus產(chǎn)品的權(quán)限管理。 ? ??
? ??
? 權(quán)限表及相關(guān)內(nèi)容大體可以用六個(gè)表來描述，如下： ? ??
? 1 ? 角色（即用戶組）表：包括三個(gè)字段，ID，角色名，對(duì)該角色的描述； ? ??
? 2 ? 用戶表：包括三個(gè)或以上字段，ID，用戶名，對(duì)該用戶的描述，其它（如地址、電話等信息）； ? ??
? 3 ? 角色-用戶對(duì)應(yīng)表：該表記錄用戶與角色之間的對(duì)應(yīng)關(guān)系，一個(gè)用戶可以隸屬于多個(gè)角色，一個(gè)角色組也可擁有多個(gè)用戶。包括三個(gè)字段，ID，角色I(xiàn)D，用戶ID； ? ??
? 4 ? 限制內(nèi)容列表：該表記錄所有需要加以權(quán)限區(qū)分限制的數(shù)據(jù)表、功能和字段等內(nèi)容及其描述，包括三個(gè)字段，ID，名稱，描述； ? ??
? 5 ? 權(quán)限列表：該表記錄所有要加以控制的權(quán)限，如錄入、修改、刪除、執(zhí)行等，也包括三個(gè)字段，ID，名稱，描述； ? ??
? 6 ? 權(quán)限-角色-用戶對(duì)應(yīng)表：一般情況下，我們對(duì)角色/用戶所擁有的權(quán)限做如下規(guī)定，角色擁有明令允許的權(quán)限，其它一律禁止，用戶繼承所屬角色的全部權(quán)限，在此范圍內(nèi)的權(quán)限除明令禁止外全部允許，范圍外權(quán)限除明令允許外全部禁止。該表的設(shè)計(jì)是權(quán)限管理的重點(diǎn)，設(shè)計(jì)的思路也很多，可以說各有千秋，不能生搬硬套說某種方法好。對(duì)此，我的看法是就個(gè)人情況，找自己覺得合適能解決問題的用。 ? ??
? ??
? 先說第一種也是最容易理解的方法，設(shè)計(jì)五個(gè)字段：ID，限制內(nèi)容ID，權(quán)限ID，角色/用戶類型（布爾型字段，用來描述一條記錄記錄的是角色權(quán)限還是用戶權(quán)限），角色/用戶ID，權(quán)限類型（布爾型字段，用來描述一條記錄表示允許還是禁止） ? ??
? ??
? 好了，有這六個(gè)表，根據(jù)表六，我們就可以知道某個(gè)角色/用戶到底擁有/禁止某種權(quán)限。 ? ??
? ??
? 或者說，這么設(shè)計(jì)已經(jīng)足夠了，我們完全實(shí)現(xiàn)了所需要的功能：可以對(duì)角色和用戶分別進(jìn)行權(quán)限定制，也具有相當(dāng)?shù)目蓴U(kuò)展性，比如說增加了新功能，我們只需要添加一條或者幾條記錄就可以，同時(shí)應(yīng)用程序接口也無須改動(dòng)，具有相當(dāng)?shù)目尚行浴５?#xff0c;在程序?qū)崿F(xiàn)的過程中，我們發(fā)現(xiàn)，使用這種方法并不是十分科學(xué)，例如瀏覽某個(gè)用戶所擁有的權(quán)限時(shí)，需要對(duì)數(shù)據(jù)庫進(jìn)行多次（甚至是遞歸）查詢，極不方便。于是我們需要想其它的辦法。使用過Unix系統(tǒng)的人們都知道，Unix文件系統(tǒng)將對(duì)文件的操作權(quán)限分為三種：讀、寫和執(zhí)行，分別用1、2、4三個(gè)代碼標(biāo)識(shí)，對(duì)用戶同時(shí)具有讀寫權(quán)限的文件被記錄為3，即1+2。我們也可以用類似的辦法來解決這個(gè)問題。初步的想法是修改權(quán)限列表，加入一個(gè)字段：標(biāo)識(shí)碼，例如，我們可以將錄入權(quán)限標(biāo)識(shí)為1，瀏覽權(quán)限標(biāo)識(shí)為2，修改權(quán)限標(biāo)識(shí)為4，刪除權(quán)限標(biāo)識(shí)為8，執(zhí)行權(quán)限標(biāo)識(shí)為16，這樣，我們通過權(quán)限累加的辦法就可以輕易的將原本要分為幾條記錄描述的權(quán)限放在一起了，例如，假定某用戶ID為1，庫存表對(duì)應(yīng)的限制內(nèi)容ID為2，同時(shí)規(guī)定角色類型為0、用戶類型為1，我們就可以將該用戶具有錄入、瀏覽、修改、刪除庫存表的權(quán)限描述為：2,15,1,1。 ? ??
? ??
? 確實(shí)很簡單，不是嗎？甚至還有更過激的辦法，將限制內(nèi)容列表也加上一列，定義好標(biāo)識(shí)碼，這樣，我們甚至可以用簡單的一條記錄描述某個(gè)用戶具有的對(duì)全部內(nèi)容所具有的全部權(quán)限了。當(dāng)然，這樣做的前提是限制內(nèi)容數(shù)量比較小，不然，呵呵，2的n次方遞增起來可是數(shù)量驚人，不容易解析的。 ? ??
? ??
? 從表面上看，上述方法足以達(dá)到實(shí)現(xiàn)功能、簡化數(shù)據(jù)庫設(shè)計(jì)及實(shí)現(xiàn)的復(fù)雜度這個(gè)目的，但這樣做有個(gè)弊端，我們所涉及的權(quán)限列表不是相互獨(dú)立而是互相依賴的，比如說修改權(quán)限，其實(shí)是包含瀏覽權(quán)限的，例如，我們可能只是簡單的設(shè)置用戶對(duì)庫存表存取的權(quán)限值為錄入+修改+刪除（1+4+8=13),但事實(shí)上，該用戶具有(1+2+4+8=15）的權(quán)限，也就是說，在這種方案中，13=15。于是當(dāng)我們調(diào)用API詢問某用戶是否具有瀏覽權(quán)限時(shí)，就必須判斷該用戶是否具有對(duì)該數(shù)據(jù)表的修改權(quán)限，因此，如果不能在程序中固化權(quán)限之間的包含關(guān)系，就不能利用應(yīng)用程序接口簡單的做出判斷。但這與我們的目的“充分的可擴(kuò)展性”矛盾。 ? ??
? ??
? 這個(gè)問題如何解決？我想到了另外一種設(shè)置標(biāo)識(shí)碼的方法，那就是利用素?cái)?shù)。我們不妨將錄入、瀏覽、修改、刪除、執(zhí)行的基本標(biāo)志碼定為2,3,5,7,11，當(dāng)遇到權(quán)限互相包含的時(shí)候，我們將它的標(biāo)識(shí)碼設(shè)定為兩個(gè)（或多個(gè)）基本標(biāo)志碼的乘積，例如，可以將“修改”功能的標(biāo)志碼定為3*5=15，然后將所有的權(quán)限相乘，就得到了我們需要的最終權(quán)限標(biāo)識(shí)值。這樣，我們?cè)谠儐栍脩羰欠窬哂心稠?xiàng)權(quán)限的時(shí)候，只需要將最終的值分解成質(zhì)因子，例如，我們可以定義一個(gè)用戶具有錄入+修改+刪除庫存表的權(quán)限為 ? 2*15*7=2*3*5*7，即表示，該用戶具有了對(duì)庫存表錄入+瀏覽+修改+刪除權(quán)限。 ? ??
? ??
? 當(dāng)然，對(duì)權(quán)限列表我們使用上述方法的前提是權(quán)限列表記錄條數(shù)不會(huì)太多并且關(guān)系不是十分復(fù)雜，否則，光是解析權(quán)限代碼就要機(jī)器忽悠半宿：） ?
通用權(quán)限管理設(shè)計(jì)篇??
?
http://sxiaomais.blog.163.com/blog/static/31741203200811102630406/
一．引言
?????? 因?yàn)樽鲞^的一些系統(tǒng)的權(quán)限管理的功能雖然在逐步完善，但總有些不盡人意的地方，總想抽個(gè)時(shí)間來更好的思考一下權(quán)限系統(tǒng)的設(shè)計(jì)。
?????? 權(quán)限系統(tǒng)一直以來是我們應(yīng)用系統(tǒng)不可缺少的一個(gè)部分，若每個(gè)應(yīng)用系統(tǒng)都重新對(duì)系統(tǒng)的權(quán)限進(jìn)行設(shè)計(jì)，以滿足不同系統(tǒng)用戶的需求，將會(huì)浪費(fèi)我們不少寶貴時(shí)間，所以花時(shí)間來設(shè)計(jì)一個(gè)相對(duì)通用的權(quán)限系統(tǒng)是很有意義的。
二．設(shè)計(jì)目標(biāo)
?????? 設(shè)計(jì)一個(gè)靈活、通用、方便的權(quán)限管理系統(tǒng)。
?????? 在這個(gè)系統(tǒng)中，我們需要對(duì)系統(tǒng)的所有資源進(jìn)行權(quán)限控制，那么系統(tǒng)中的資源包括哪些呢？我們可以把這些資源簡單概括為靜態(tài)資源（功能操作、數(shù)據(jù)列）和動(dòng)態(tài)資源（數(shù)據(jù)），也分別稱為對(duì)象資源和數(shù)據(jù)資源，后者是我們?cè)谙到y(tǒng)設(shè)計(jì)與實(shí)現(xiàn)中的叫法。
系統(tǒng)的目標(biāo)就是對(duì)應(yīng)用系統(tǒng)的所有對(duì)象資源和數(shù)據(jù)資源進(jìn)行權(quán)限控制，比如應(yīng)用系統(tǒng)的功能菜單、各個(gè)界面的按鈕、數(shù)據(jù)顯示的列以及各種行級(jí)數(shù)據(jù)進(jìn)行權(quán)限的操控。
三．相關(guān)對(duì)象及其關(guān)系
?????? 大概理清了一下權(quán)限系統(tǒng)的相關(guān)概念，如下所示：
1.?????? 權(quán)限
系統(tǒng)的所有權(quán)限信息。權(quán)限具有上下級(jí)關(guān)系，是一個(gè)樹狀的結(jié)構(gòu)。下面來看一個(gè)例子
系統(tǒng)管理
??????? 用戶管理
??????? ?????? 查看用戶
??????????????? 新增用戶
???????????????????? 修改用戶
???????????????????? 刪除用戶
?????? 對(duì)于上面的每個(gè)權(quán)限，又存在兩種情況，一個(gè)是只是可訪問，另一種是可授權(quán)，例如對(duì)于“查看用戶”這個(gè)權(quán)限，如果用戶只被授予“可訪問”，那么他就不能將他所具有的這個(gè)權(quán)限分配給其他人。
2.?????? 用戶
應(yīng)用系統(tǒng)的具體操作者，用戶可以自己擁有權(quán)限信息，可以歸屬于0～n個(gè)角色，可屬于0～n個(gè)組。他的權(quán)限集是自身具有的權(quán)限、所屬的各角色具有的權(quán)限、所屬的各組具有的權(quán)限的合集。它與權(quán)限、角色、組之間的關(guān)系都是n對(duì)n的關(guān)系。
3.?????? 角色
為了對(duì)許多擁有相似權(quán)限的用戶進(jìn)行分類管理，定義了角色的概念，例如系統(tǒng)管理員、管理員、用戶、訪客等角色。角色具有上下級(jí)關(guān)系，可以形成樹狀視圖，父級(jí)角色的權(quán)限是自身及它的所有子角色的權(quán)限的綜合。父級(jí)角色的用戶、父級(jí)角色的組同理可推。
4.?????? 組
為了更好地管理用戶，對(duì)用戶進(jìn)行分組歸類，簡稱為用戶分組。組也具有上下級(jí)關(guān)系，可以形成樹狀視圖。在實(shí)際情況中，我們知道，組也可以具有自己的角色信息、權(quán)限信息。這讓我想到我們的QQ用戶群，一個(gè)群可以有多個(gè)用戶，一個(gè)用戶也可以加入多個(gè)群。每個(gè)群具有自己的權(quán)限信息。例如查看群共享。QQ群也可以具有自己的角色信息，例如普通群、高級(jí)群等。
針對(duì)上面提出的四種類型的對(duì)象，讓我們通過圖來看看他們之間的關(guān)系。
?
????有上圖中可以看出，這四者的關(guān)系很復(fù)雜，而實(shí)際的情況比這個(gè)圖還要復(fù)雜，權(quán)限、角色、組都具有上下級(jí)關(guān)系，權(quán)限管理是應(yīng)用系統(tǒng)中比較棘手的問題，要設(shè)計(jì)一個(gè)通用的權(quán)限管理系統(tǒng)，工作量也著實(shí)不小。
當(dāng)然對(duì)于有些項(xiàng)目，權(quán)限問題并不是那么復(fù)雜。有的只需要牽涉到權(quán)限和用戶兩種類型的對(duì)象，只需要給用戶分配權(quán)限即可。
在另一些情況中，引入了角色對(duì)象，例如基于角色的權(quán)限系統(tǒng)， 只需要給角色分配權(quán)限，用戶都隸屬于角色，不需要單獨(dú)為用戶分配角色信息。
通用權(quán)限管理設(shè)計(jì)篇（二）——數(shù)據(jù)庫設(shè)計(jì)
?? 國慶前整的通用權(quán)限設(shè)計(jì)的數(shù)據(jù)庫初步設(shè)計(jì)部分，現(xiàn)在貼上來。
理清了對(duì)象關(guān)系之后，讓我們接著來進(jìn)行數(shù)據(jù)庫的設(shè)計(jì)。在數(shù)據(jù)庫建模時(shí)，對(duì)于N對(duì)N的
關(guān)系，一般需要加入一個(gè)關(guān)聯(lián)表來表示關(guān)聯(lián)的兩者的關(guān)系。初步估計(jì)一下，本系統(tǒng)至少需要十張表，分別為：權(quán)限表、用戶表、角色表、組表、用戶權(quán)限關(guān)聯(lián)表、用
戶角色關(guān)聯(lián)表、角色權(quán)限關(guān)聯(lián)表、組權(quán)限關(guān)聯(lián)表、組角色關(guān)聯(lián)表、用戶屬組關(guān)聯(lián)表。當(dāng)然還可能引出一些相關(guān)的表。下面讓我們?cè)赑owerDesigner中畫出各表吧。
?????? 各表及其關(guān)系如下：
??????
1.?????? 用戶表
?
| ? 用戶表（TUser） | |||
| ? 字段名稱 | ? 字段 | ? 類型 | ? 備注 |
| ? 記錄標(biāo)識(shí) | ? tu_id | ? bigint | ? pk, not null |
| ? 所屬組織 | ? to_id | ? bigint | ? fk, not null |
| ? 登錄帳號(hào) | ? login_name | ? varchar(64) | ? not null |
| ? 用戶密碼 | ? password | ? varchar(64) | ? not null |
| ? 用戶姓名 | ? vsername | ? varchar(64) | ? not null |
| ? 手機(jī)號(hào) | ? mobile | ? varchar(20) | ? |
| ? 電子郵箱 | ? | ? varchar(64) | ? |
| ? 創(chuàng)建時(shí)間 | ? gen_time | ? datetime | ? not null |
| ? 登錄時(shí)間 | ? login_time | ? datetime | ? |
| ? 上次登錄時(shí)間 | ? last_login_time | ? datetime | ? |
| ? 登錄次數(shù) | ? count | ? bigint | ? not null |
?
2.?????? 角色表
?
| ? 角色表（TRole） | |||
| ? 字段名稱 | ? 字段 | ? 類型 | ? 備注 |
| ? 角色I(xiàn)D | ? tr_id | ? bigint | ? pk, not null |
| ? 父級(jí)角色I(xiàn)D | ? parent_tr_id | ? bigint | ? not null |
| ? 角色名稱 | ? role_name | ? varchar(64) | ? not null |
| ? 創(chuàng)建時(shí)間 | ? gen_time | ? datetime | ? not null |
| ? 角色描述 | ? description | ? varchar(200) | ? |
?
3.?????? 權(quán)限表
?
| ? 權(quán)限表（TRight） | |||
| ? 字段名稱 | ? 字段 | ? 類型 | ? 備注 |
| ? 權(quán)限ID | ? tr_id | ? bigint | ? pk, not null |
| ? 父權(quán)限 | ? parent_tr_id | ? bigint | ? not null |
| ? 權(quán)限名稱 | ? right_name | ? varchar(64) | ? not null |
| ? 權(quán)限描述 | ? description | ? varchar(200) | ? |
?
4.?????? 組表
?
| ? 組表（TGroup） | |||
| ? 字段名稱 | ? 字段 | ? 類型 | ? 備注 |
| ? 組ID | ? tg_id | ? bigint | ? pk, not null |
| ? 組名稱 | ? group_name | ? varchar(64) | ? not null |
| ? 父組 | ? parent_tg_id | ? bigint | ? not null |
| ? 創(chuàng)建時(shí)間 | ? gen_time | ? datetime | ? not null |
| ? 組描述 | ? description | ? varchar(200) | ? |
?
5.?????? 角色權(quán)限表
?
| ? 角色權(quán)限表（TRoleRightRelation） | |||
| ? 字段名稱 | ? 字段 | ? 類型 | ? 備注 |
| ? 記錄標(biāo)識(shí) | ? trr_id | ? bigint | ? pk, not null |
| ? 角色 | ? Role_id | ? bigint | ? fk, not null |
| ? 權(quán)限 | ? right_id | ? bigint | ? fk, not null |
| ? 權(quán)限類型 | ? right_type | ? int | ? not null（0:可訪問，1:可授權(quán)） |
?
6.?????? 組權(quán)限表
?
| ? 組權(quán)限表（TGroupRightRelation） | |||
| ? 字段名稱 | ? 字段 | ? 類型 | ? 備注 |
| ? 記錄標(biāo)識(shí) | ? tgr_id | ? bigint | ? pk, not null |
| ? 組 | ? tg_id | ? bigint | ? fk, not null |
| ? 權(quán)限 | ? tr_id | ? bigint | ? fk, not null |
| ? 權(quán)限類型 | ? right_type | ? int | ? not null（0:可訪問，1:可授權(quán)） |
?
7.?????? 組角色表
?
| ? 組角色表（TGroupRoleRelation） | |||
| ? 字段名稱 | ? 字段 | ? 類型 | ? 備注 |
| ? 記錄標(biāo)識(shí) | ? tgr_id | ? bigint | ? pk, not null |
| ? 組 | ? tg_id | ? bigint | ? fk, not null |
| ? 角色 | ? tr_id | ? bigint | ? pk, not null |
?
8.?????? 用戶權(quán)限表
?
| ? 用戶權(quán)限表（TUserRightRelation） | |||
| ? 字段名稱 | ? 字段 | ? 類型 | ? 備注 |
| ? 記錄標(biāo)識(shí) | ? tur_id | ? bigint | ? pk, not null |
| ? 用戶 | ? tu_id | ? bigint | ? fk, not null |
| ? 權(quán)限 | ? tr_id | ? bigint | ? fk, not null |
| ? 權(quán)限類型 | ? right_type | ? int | ? not null（0:可訪問，1:可授權(quán)） |
?
9.?????? 用戶角色表
?
| ? 用戶角色表（TUserRoleRelation） | |||
| ? 字段名稱 | ? 字段 | ? 類型 | ? 備注 |
| ? 記錄標(biāo)識(shí) | ? tur_id | ? bigint | ? pk, not null |
| ? 用戶 | ? tu_id | ? bigint | ? fk, not null |
| ? 角色 | ? tr_id | ? bigint | ? fk, not null |
?
10.?? 用戶組表
?
| ? 用戶組表（TUserGroupRelation） | |||
| ? 字段名稱 | ? 字段 | ? 類型 | ? 備注 |
| ? 記錄標(biāo)識(shí) | ? tug_id | ? bigint | ? pk, not null |
| ? 用戶 | ? tu_id | ? bigint | ? fk, not null |
| ? 組 | ? tg_id | ? bigint | ? fk, not null |
?
11.?? 組織表
?
| ? 組織表（TOrganization） | |||
| ? 字段名稱 | ? 字段 | ? 類型 | ? 備注 |
| ? 組織id | ? to_id | ? bigint | ? pk, not null |
| ? 父組 | ? parent_to_id | ? bigint | ? not null |
| ? 組織名稱 | ? org_name | ? varchar(64) | ? not null |
| ? 創(chuàng)建時(shí)間 | ? gen_time | ? datetime | ? not null |
| ? 組織描述 | ? description | ? varchar(200) | ? |
?
12.?? 操作日志表
?
| ? 操作日志表（TLog） | |||
| ? 字段名稱 | ? 字段 | ? 類型 | ? 備注 |
| ? 日志ID | ? log_id | ? bigint | ? pk, not null |
| ? 操作類型 | ? op_type | ? int | ? not null |
| ? 操作內(nèi)容 | ? content | ? varchar(200) | ? not null |
| ? 操作人 | ? tu_id | ? bigint | ? fk, not null |
| ? 操作時(shí)間 | ? gen_time | ? datetime | ? not null |
?
通用權(quán)限管理系統(tǒng)設(shè)計(jì)篇（三）——概要設(shè)計(jì)說明書
?在前兩篇文章中，不少朋友對(duì)我的設(shè)計(jì)提出了異議，認(rèn)為過于復(fù)雜，當(dāng)然在實(shí)際的各種系統(tǒng)的權(quán)限管理模塊中，并不像這里設(shè)計(jì)得那么復(fù)雜，我以前所做的系統(tǒng)中，
由只有用戶和權(quán)限的，有只有用戶、權(quán)限和角色的，還有一個(gè)系統(tǒng)用到了用戶、權(quán)限、角色、組概念，這個(gè)系統(tǒng)是我在思考以前所做系統(tǒng)的權(quán)限管理部分中找到的一
些共性而想到的一個(gè)設(shè)計(jì)方案，當(dāng)然還會(huì)有不少設(shè)計(jì)不到位的地方，在設(shè)計(jì)開發(fā)過程中會(huì)慢慢改進(jìn)，這個(gè)系統(tǒng)權(quán)當(dāng)學(xué)習(xí)只用，各位朋友的好的建議我都會(huì)考慮到設(shè)計(jì)
中，感謝各位朋友的支持。
??? 今天抽時(shí)間整了一份概念設(shè)計(jì)出來，還有一些地方尚未考慮清楚，貼出1.0版，希望各位朋友提出寶貴建議。
??? 大家也可以點(diǎn)擊此處《通用權(quán)限管理概要設(shè)計(jì)說明書》自行下載，這是1.0版本，有些地方可能還會(huì)進(jìn)行部分修改，有興趣的朋友請(qǐng)關(guān)注我的blog。
?????
1.????? 引言
1.1 編寫目的
本文檔對(duì)通用權(quán)限管理系統(tǒng)的總體設(shè)計(jì)、接口設(shè)計(jì)、界面總體設(shè)計(jì)、數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)、系統(tǒng)出錯(cuò)處理設(shè)計(jì)以及系統(tǒng)安全數(shù)據(jù)進(jìn)行了說明。
1.2 背景
a、?軟件系統(tǒng)的名稱：通用權(quán)限管理系統(tǒng)；
b、?任務(wù)提出者、開發(fā)者：謝星星；
c、?在J2EE的web系統(tǒng)中需要使用權(quán)限管理的系統(tǒng)。
1.3 術(shù)語
本系統(tǒng)：通用權(quán)限管理系統(tǒng)；
SSH：英文全稱是Secure Shell。
1.4 預(yù)期讀者與閱讀建議
?
| ? 預(yù)期讀者 | ? 閱讀重點(diǎn) |
| ? 開發(fā)人員 | ? 總體設(shè)計(jì)、接口設(shè)計(jì)、數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)、界面總體設(shè)計(jì)、系統(tǒng)出錯(cuò)處理設(shè)計(jì) |
| ? 設(shè)計(jì)人員 | ? 總體設(shè)計(jì)、接口設(shè)計(jì)、數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)、系統(tǒng)安全設(shè)計(jì) |
?
1.5 參考資料
《通用權(quán)限管理系統(tǒng)需求規(guī)格說明書》
《通用權(quán)限管理系統(tǒng)數(shù)據(jù)庫設(shè)計(jì)說明書》
2.????? 總體設(shè)計(jì)
2.1 設(shè)計(jì)目標(biāo)
權(quán)限系統(tǒng)一直以來是我們應(yīng)用系統(tǒng)不可缺少的一個(gè)部分，若每個(gè)應(yīng)用系統(tǒng)都重新對(duì)系統(tǒng)的權(quán)限進(jìn)行設(shè)計(jì)，以滿足不同系統(tǒng)用戶的需求，將會(huì)浪費(fèi)我們不少寶貴時(shí)間，所以花時(shí)間來設(shè)計(jì)一個(gè)相對(duì)通用的權(quán)限系統(tǒng)是很有意義的。
本系統(tǒng)的設(shè)計(jì)目標(biāo)是對(duì)應(yīng)用系統(tǒng)的所有資源進(jìn)行權(quán)限控制，比如應(yīng)用系統(tǒng)的功能菜單、各個(gè)界面的按鈕控件等進(jìn)行權(quán)限的操控。
2.2 運(yùn)行環(huán)境
操作系統(tǒng)：Windows系統(tǒng)操作系統(tǒng)和Linux系列操作系統(tǒng)。
2.3 網(wǎng)絡(luò)結(jié)構(gòu)
?通用權(quán)限管理系統(tǒng)可采用Java Swing實(shí)現(xiàn)，可以在桌面應(yīng)用和Web應(yīng)用系統(tǒng)中進(jìn)行調(diào)用。如果需要要適應(yīng)所有開發(fā)語言，可以將其API發(fā)布到WEB Service上。暫時(shí)用Java Swing實(shí)現(xiàn)。
2.4 總體設(shè)計(jì)思路和處理流程
在說明總體設(shè)計(jì)思路前，我們先說明本系統(tǒng)的相關(guān)概念：
1. 權(quán)限資源
系統(tǒng)的所有權(quán)限信息。權(quán)限具有上下級(jí)關(guān)系，是一個(gè)樹狀的結(jié)構(gòu)。下面來看一個(gè)例子
系統(tǒng)管理
??????? 用戶管理
??????? ?????? 查看用戶
???????????????新增用戶
???????????????修改用戶
???????????????刪除用戶
對(duì)于上面的每個(gè)權(quán)限，又存在兩種情況，一個(gè)是只是可訪問，另一種是可授權(quán)，例如對(duì)于“查看用戶”這個(gè)權(quán)限，如果用戶只被授予“可訪問”，那么他就不能將他所具有的這個(gè)權(quán)限分配給其他人。
2. 用戶
應(yīng)用系統(tǒng)的具體操作者，用戶可以自己擁有權(quán)限信息，可以歸屬于0～n個(gè)角色，可屬于0～n個(gè)組。他的權(quán)限集是自身具有的權(quán)限、所屬的各角色具有的權(quán)限、所屬的各組具有的權(quán)限的合集。它與權(quán)限、角色、組之間的關(guān)系都是n對(duì)n的關(guān)系。
3. 角色
為了對(duì)許多擁有相似權(quán)限的用戶進(jìn)行分類管理，定義了角色的概念，例如系統(tǒng)管理員、管理員、用戶、訪客等角色。角色具有上下級(jí)關(guān)系，可以形成樹狀視圖，父級(jí)角色的權(quán)限是自身及它的所有子角色的權(quán)限的綜合。父級(jí)角色的用戶、父級(jí)角色的組同理可推。
4. 組
為
了更好地管理用戶，對(duì)用戶進(jìn)行分組歸類，簡稱為用戶分組。組也具有上下級(jí)關(guān)系，可以形成樹狀視圖。在實(shí)際情況中，我們知道，組也可以具有自己的角色信息、
權(quán)限信息。這讓我想到我們的QQ用戶群，一個(gè)群可以有多個(gè)用戶，一個(gè)用戶也可以加入多個(gè)群。每個(gè)群具有自己的權(quán)限信息。例如查看群共享。QQ群也可以具有
自己的角色信息，例如普通群、高級(jí)群等。
針對(duì)如上提出的四種對(duì)象，我們可以整理得出它們之間的關(guān)系圖，如下所示：
?
總體設(shè)計(jì)思路是將系統(tǒng)分為組權(quán)限管理、角色權(quán)限管理、用戶權(quán)限管理、組織管理和操作日志管理五部分。
其中組權(quán)限管理包括包含用戶、所屬角色、組權(quán)限資源和組總權(quán)限資源四部分，某個(gè)組的權(quán)限信息可用公式表示：組權(quán)限 = 所屬角色的權(quán)限合集 + 組自身的權(quán)限。
角色權(quán)限管理包括包含用戶、包含組和角色權(quán)限三部分，某個(gè)角色的權(quán)限的計(jì)算公式為：角色權(quán)限 = 角色自身權(quán)限。
用戶權(quán)限管理包括所屬角色、所屬組、用戶權(quán)限、用戶總權(quán)限資源和組織管理五部分。某個(gè)用戶總的權(quán)限信息存在如下計(jì)算公式：用戶權(quán)限 = 所屬角色權(quán)限合集 + 所屬組權(quán)限合集 + 用戶自身權(quán)限。
組織管理即對(duì)用戶所屬的組織進(jìn)行管理，組織以樹形結(jié)構(gòu)展示，組織管理具有組織的增、刪、改、查功能。
操作日志管理用于管理本系統(tǒng)的操作日志。
注意：因?yàn)榻M和角色都具有上下級(jí)關(guān)系，所以下級(jí)的組或角色的權(quán)限只能在自己的直屬上級(jí)的權(quán)限中選擇，下級(jí)的組或者角色的總的權(quán)限都不能大于直屬上級(jí)的總權(quán)限。
2.5 模塊結(jié)構(gòu)設(shè)計(jì)
本系統(tǒng)的具有的功能模塊結(jié)構(gòu)如下圖所示：
2.6 尚未解決的問題
無。
3.????? 接口設(shè)計(jì)（暫略）
3.1 用戶接口（暫略）
3.2 外部接口（暫略）
3.3 內(nèi)部接口（暫略）
4.????? 界面總體設(shè)計(jì)
本節(jié)將闡述用戶界面的實(shí)現(xiàn)，在此之前對(duì)頁面元素做如下約定：
?
| ? 序號(hào) | ? 頁面元素 | ? 約定 |
| ? 1 | ? 按鈕 | ? 未選中時(shí)：[按鈕名稱] 選中時(shí)：[按鈕名稱] |
| ? 2 | ? 單選框 | ? ○ 選項(xiàng) |
| ? 3 | ? 復(fù)選框 | ? □ 選項(xiàng) |
| ? 4 | ? 下拉框 | ? ?[選項(xiàng),…,] ▽ |
| ? 5 | ? 文本框 | ? ?|________| |
| ? 6 | ? TextArea | ? ?|…………| |
| ? 7 | ? 頁簽 | ? 未選中時(shí)：選項(xiàng)名稱 ?選中時(shí)：選項(xiàng)名稱 |
| ? 8 | ? 未選中鏈接 | ? 鏈接文字 |
| ? 9 | ? 選中鏈接 | ? 鏈接文字 |
| ? 10 | ? 說明信息 | ? 說明信息 |
?
?
4.1 組權(quán)限管理
4.1.1包含用戶
?
| ? 組信息 ?? 組1 ?????? 組11 ?????? 組12 ?????? 組… ?? 組2 ?????? 組21 ?????? 組22 ?????? 組… ? | ? 所選擇組：組1 [包含用戶] [所屬角色] [組權(quán)限] [總權(quán)限] [修改] 用戶名?? 姓名???? 手機(jī)號(hào)?? 最近登錄時(shí)間?登錄次數(shù) 阿蜜果?謝星星?13666666666?2007-10-8??? 66 sterning xxx??? 13555555555?2007-10-8??? 10? …… |
?
當(dāng)用戶選擇“修改”按鈕時(shí)，彈出用戶列表，操作人可以通過勾選或取消勾選來修改該組所包含的用戶。
4.1.2所屬角色
?
| ? 組信息 ?? 組1 ?????? 組11 ?????? 組12 ?????? 組… ?? 組2 ?????? 組21 ?????? 組22 ?????? 組… ? | ? 所選擇組：組1 [包含用戶] [所屬角色] [組權(quán)限] [總權(quán)限] [修改] 角色I(xiàn)D?? 角色名稱?? 角色描述 1????????? 訪客?????? -- ?? 2???????? 初級(jí)用戶??? -- ?? |
?
當(dāng)用戶選擇“修改”按鈕時(shí)，彈出角色樹形結(jié)構(gòu)，操作人可以通過勾選或取消勾選來修改該組所屬的角色。
4.1.3組權(quán)限
?
| ? 組信息 ?? 組1 ?????? 組11 ?????? 組12 ?????? 組… ?? 組2 ?????? 組21 ?????? 組22 ?????? 組… ? | ? 所選擇組：組1 [包含用戶] [所屬角色] [組權(quán)限] [總權(quán)限]
??????????????? [保存] [取消] |
?
4.1.4總權(quán)限
?
| ? 組信息 ?? 組1 ?????? 組11 ?????? 組12 ?????? 組… ?? 組2 ?????? 組21 ?????? 組22 ?????? 組… ? | ? 所選擇組：組1 [包含用戶] [所屬角色] [組權(quán)限] [總權(quán)限]
??????????????? [保存] [取消] |
?
通過對(duì)已具有的權(quán)限取消勾選，或?yàn)槟硻?quán)限添加勾選，來修改組的權(quán)限信息，點(diǎn)擊“保存”按鈕保存修改信息。
4.1.5組管理
?????? 在下圖中，選中組1的時(shí)候，右鍵點(diǎn)擊可彈出組的操作列表，包括添加、刪除和修改按鈕，從而完成在該組下添加子組，刪除該組以及修改該組的功能。
?
| ? 組信息 ?? 組1 ?????? 組11 ?????? 組12 ?????? 組… ?? 組2 ?????? 組21 ?????? 組22 ?????? 組… ? | ? 所選擇組：組1 [包含用戶] [所屬角色] [組權(quán)限] [總權(quán)限] [修改] 用戶名?? 姓名???? 手機(jī)號(hào)?? 最近登錄時(shí)間?登錄次數(shù) 阿蜜果?謝星星?13666666666?2007-10-8??? 66 sterning xxx??? 13555555555?2007-10-8??? 10? …… |
?
4.2 角色權(quán)限管理
4.2.1包含用戶
?
| ? 角色信息 ?? 角色1 ?????? 角色11 ?????? 角色12 ?????? 角色… ?? 角色2 ?????? 角色21 ?????? 角色22 ?????? 角色… ? | ? 所選擇角色：角色1 [包含用戶] [包含組] [角色權(quán)限] [修改] 用戶名?? 姓名???? 手機(jī)號(hào)?? 最近登錄時(shí)間?登錄次數(shù) 阿蜜果?謝星星?13666666666?2007-10-8??? 66 sterning xxx??? 13555555555?2007-10-8??? 10? …… |
?
當(dāng)用戶選擇“修改”按鈕時(shí)，彈出用戶列表，操作人可以通過勾選或取消勾選來修改該角色所包含的用戶。
4.2.2包含組
?
| ? 角色信息 ?? 角色1 ?????? 角色11 ?????? 角色12 ?????? 角色… ?? 角色2 ?????? 角色21 ?????? 角色22 ?????? 角色… ? | ? 所選擇角色：角色1 [包含用戶] [包含組] [角色權(quán)限] [修改] 組ID?? 組名稱???? 組描述 1??????xxx1???????-- 2 ??????xxx2??? ????--? …… |
?
當(dāng)用戶選擇“修改”按鈕時(shí)，彈出用戶列表，操作人可以通過勾選或取消勾選來修改該角色所包含的組。
4.2.3角色權(quán)限
?
| ? 角色信息 ?? 角色1 ?????? 角色11 ?????? 角色12 ?????? 角色… ?? 角色2 ?????? 角色21 ?????? 角色22 ?????? 角色… ? | ? 所選擇角色：角色1 [包含用戶] [包含組] [角色權(quán)限] ????????????????? ???????????????[保存] [取消] |
?
通過對(duì)已具有的權(quán)限取消勾選，或?yàn)槟硻?quán)限添加勾選，來修改角色的權(quán)限信息，點(diǎn)擊“保存”按鈕保存修改信息。
4.2.4管理角色
?????? 在下圖中，選中組1的時(shí)候，右鍵點(diǎn)擊可彈出組的操作列表，包括添加、刪除和修改按鈕，從而完成在該組下添加子組，刪除該組以及修改該組的功能。
?
| ? 角色信息 ?? 角色1 ?????? 角色11 ?????? 角色12 ?????? 角色… ?? 角色2 ?????? 角色21 ?????? 角色22 ?????? 角色… ? | ? 所選擇角色：角色1 [包含用戶] [包含組] [角色權(quán)限] [修改] 用戶名?? 姓名???? 手機(jī)號(hào)?? 最近登錄時(shí)間?登錄次數(shù) 阿蜜果?謝星星?13666666666?2007-10-8??? 66 sterning xxx??? 13555555555?2007-10-8??? 10? …… |
?
4.3 用戶權(quán)限管理
4.3.1所屬角色
?
| ? 用戶權(quán)限信息 xx公司 ?? 廣州分公司 ?????? 阿蜜果 ?????? 肖xx ?????? yy… ?? 北京分公司 ?????? zz1 ?????? zz2 ?????? zz3… ? | ? 所選擇用戶：阿蜜果 [所屬角色] [所屬組] [用戶權(quán)限] [總權(quán)限] [修改] 角色I(xiàn)D?? 角色名稱?? 角色描述 1????????? 訪客?????? -- ?? 2???????? 初級(jí)用戶??? -- … |
?
當(dāng)用戶選擇“修改”按鈕時(shí)，彈出角色樹形結(jié)構(gòu)，操作人可以通過勾選或取消勾選來修改該用戶所屬的角色。
4.3.2所屬組
?
| ? 用戶信息 xx公司 ?? 廣州分公司 ?????? 阿蜜果 ?????? 肖xx ?????? yy… ?? 北京分公司 ?????? zz1 ?????? zz2 ?????? zz3… ? | ? 所選擇用戶：阿蜜果 [所屬角色] [所屬組] [用戶權(quán)限] [總權(quán)限] [修改] 組ID?? 組名稱???? 組描述 1?????? 組1???????? -- ?? 2?????? 組2???????? -- … |
?
當(dāng)用戶選擇“修改”按鈕時(shí)，彈出組的樹形結(jié)構(gòu)，操作人可以通過勾選或取消勾選來修改該用戶所屬的組。
4.3.3用戶權(quán)限
?
| ? 用戶信息 xx公司 ?? 廣州分公司 ?????? 阿蜜果 ?????? 肖xx ?????? yy… ?? 北京分公司 ?????? zz1 ?????? zz2 ?????? zz3… ? | ? 所選擇用戶：阿蜜果 [所屬角色] [所屬組] [用戶權(quán)限] [總權(quán)限] ????????????????? ????????????????[保存] [取消] |
?
通過對(duì)已具有的權(quán)限取消勾選，或?yàn)槟硻?quán)限添加勾選，來修改用戶的權(quán)限信息，點(diǎn)擊“保存”按鈕保存修改信息。
4.3.4總權(quán)限
?
| ? 用戶信息 xx公司 ?? 廣州分公司 ?????? 阿蜜果 ?????? 肖xx ?????? yy… ?? 北京分公司 ?????? zz1 ?????? zz2 ?????? zz3… ? | ? 所選擇用戶：阿蜜果 [所屬角色] [所屬組] [用戶權(quán)限] [總權(quán)限] ????????????????? ????????????????[保存] [取消] |
?
通過對(duì)已具有的權(quán)限取消勾選，或?yàn)槟硻?quán)限添加勾選，來修改用戶的權(quán)限信息，點(diǎn)擊“保存”按鈕保存修改信息。
4.3.5用戶管理
?????? 當(dāng)選擇了某用戶時(shí)，點(diǎn)擊右鍵，彈出菜單列表：修改、刪除、取消，點(diǎn)擊修改和刪除按鈕可以實(shí)現(xiàn)用戶的刪除和修改功能。
?????? 選擇某個(gè)組織，例如下表中的“廣州分公司”，彈出菜單列表：添加子組織、刪除組織、修改組織、添加用戶、取消，點(diǎn)擊添加用戶按鈕可以實(shí)現(xiàn)用戶的添加功能。
?
| ? 用戶權(quán)限信息 xx公司 ?? 廣州分公司 ?????? 阿蜜果 ?????? 肖xx ????? ?yy… ?? 北京分公司 ?????? zz1 ?????? zz2 ?????? zz3… ? | ? 所選擇用戶：阿蜜果 [所屬角色] [所屬組] [用戶權(quán)限] [總權(quán)限] [修改] 角色I(xiàn)D?? 角色名稱?? 角色描述 1????????? 訪客?????? -- ?? 2???????? 初級(jí)用戶??? -- … |
?
4.3.6組織管理
?????? 選擇某個(gè)組織，例如下表中的“廣州分公司”，彈出菜單列表：添加子組織、刪除組織、修改組織、添加用戶、取消，點(diǎn)擊添加子組織、刪除組織、修改組織按鈕可以實(shí)現(xiàn)組織的添加、刪除和修改功能。
?
| ? 用戶權(quán)限信息 xx公司 ?? 廣州分公司 ?????? 阿蜜果 ?????? 肖xx ?????? yy… ?? 北京分公司 ?????? zz1 ?????? zz2 ?????? zz3… ? | ? 所選擇用戶：阿蜜果 [所屬角色] [所屬組] [用戶權(quán)限] [總權(quán)限] [修改] 角色I(xiàn)D?? 角色名稱?? 角色描述 1????????? 訪客?????? -- ?? 2???????? 初級(jí)用戶??? -- … |
?
4.4 操作日志管理
4.4.1查詢操作日志
?
| ? 操作名稱：|________| ?操作人：|________| 操作時(shí)間從?|________| 到 |________|?[查詢] [重置] [刪除] 編號(hào)?? ?操作名稱?? ?操作內(nèi)容?? ?操作人?? ?操作時(shí)間 1??????? xx1?????? ??--??????? Amigo?? ?2007-10-8 2??????? xx2??? ?????--??????? xxyy?? ??2007-10-8 … |
?
輸入上圖表單中的查詢信息后，點(diǎn)擊“查詢”按鈕，可查詢出符合條件的信息。
4.4.2刪除操作日志
?
| ? 操作名稱：|________|?操作人：|________| 操作時(shí)間從?|________| 到 |________|?[查詢] [重置] [刪除] 編號(hào)?? ?操作名稱??? 操作內(nèi)容??? 操作人??? 操作時(shí)間 1??????? xx1?????? --?????????? Amigo????? 2007-10-8 2??????? xx2?????? --?????????? xxyy?????? 2007-10-8 … |
?
輸入上圖表單中的查詢信息后，點(diǎn)擊“查詢”按鈕，可查詢出符合條件的信息。而后點(diǎn)擊“刪除”按鈕，可刪除符合查詢條件的操作日志。
5.????? 數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)
數(shù)據(jù)庫設(shè)計(jì)的模型請(qǐng)參見《通用權(quán)限管理系統(tǒng)_數(shù)據(jù)庫模型.pdm》。表的說明請(qǐng)參見《通用權(quán)限管理系統(tǒng)數(shù)據(jù)庫設(shè)計(jì)說明書》。
5.1 設(shè)計(jì)原則
5.1.1命名的規(guī)范
數(shù)據(jù)庫中表、主鍵、外鍵、索引的命名都以統(tǒng)一的規(guī)則，采用大小寫敏感的形式，各種對(duì)象命名長度不要超過30個(gè)字符，這樣便于應(yīng)用系統(tǒng)適應(yīng)不同的數(shù)據(jù)庫平臺(tái)。
5.1.2數(shù)據(jù)的一致性和完整性
為了保證數(shù)據(jù)庫的一致性和完整性，往往通過表間關(guān)聯(lián)的方式來盡可能的降低數(shù)據(jù)的冗余。表間關(guān)聯(lián)是一種強(qiáng)制性措施，建立后，對(duì)父表（Parent Table）和子表(Child Table)的插入、更新、刪除操作均要占用系統(tǒng)的開銷。如果數(shù)據(jù)冗余低，數(shù)據(jù)的完整性容易得到保證，但增加了表間連接查詢的操作，為了提高系統(tǒng)的響應(yīng)時(shí)間，合理的數(shù)據(jù)冗余也是必要的。使用規(guī)則（Rule）和約束（Check）來防止系統(tǒng)操作人員誤輸入造成數(shù)據(jù)的錯(cuò)誤是設(shè)計(jì)人員的另一種常用手段，但是，不必要的規(guī)則和約束也會(huì)占用系統(tǒng)的不必要開銷，需要注意的是，約束對(duì)數(shù)據(jù)的有效性驗(yàn)證要比規(guī)則快。所有這些，需要在設(shè)計(jì)階段應(yīng)根據(jù)系統(tǒng)操作的類型、頻度加以均衡考慮。
5.2 數(shù)據(jù)庫環(huán)境說明
數(shù)據(jù)庫：MySql5.0
設(shè)計(jì)庫建模工具：PowerDesigner12.0
5.3 數(shù)據(jù)庫命名規(guī)則
表名以T開頭，外鍵以FK開頭，索引以INDEX開頭。
5.4 邏輯結(jié)構(gòu)
pdm文件的名稱為：《通用權(quán)限管理系統(tǒng)_數(shù)據(jù)庫模型》。
5.5 物理存儲(chǔ)
通過數(shù)據(jù)庫建模工具PowerDesigner12可以將pdm導(dǎo)出為文本文件，將數(shù)據(jù)庫腳本放入文本文件中保存。
5.6 數(shù)據(jù)備份和恢復(fù)
數(shù)據(jù)庫需定期備份（每天備份一次），備份文件格式為backup_yyyyMMdd，數(shù)據(jù)庫被破壞時(shí)，利用最新的備份文件進(jìn)行恢復(fù)。
6.????? 系統(tǒng)出錯(cuò)處理設(shè)計(jì)
6.1 出錯(cuò)信息
?
| ? 錯(cuò)誤分類 | ? 子項(xiàng)及其編碼 | ? 錯(cuò)誤名稱 | ? 錯(cuò)誤代碼 | ? 備注 |
| ? 數(shù)據(jù)庫錯(cuò)誤 | ? 連接 | ? 連接超時(shí) | ? 100001001 | ? |
| ? 連接斷開 | ? 100001002 | ? | ||
| ? 數(shù)據(jù)庫本身錯(cuò)誤代碼 | ? 數(shù)據(jù)庫本身錯(cuò)誤代碼 | ? 100002+數(shù)據(jù)庫錯(cuò)誤代碼 | ? | |
| ? TCP連接錯(cuò)誤 | ? 連接 | ? 連接超時(shí) | ? 101001001 | ? |
| ? 連接斷開 | ? 101001002 | ? | ||
| ? 其它TCP連接錯(cuò)誤(socket自身錯(cuò)誤代碼) | ? | ? 101002+ socket錯(cuò)誤代碼 | ? | |
| ? 配置信息錯(cuò)誤 | ? 未配置輸入?yún)?shù) | ? | ? 102001 | ? |
| ? 未配置輸出參數(shù) | ? | ? 102002 | ? | |
| ? 組管理部分自定義錯(cuò)誤 | ? | ? | ? 103001——103999 | ? |
| ? 角色管理部分自定義錯(cuò)誤 | ? | ? | ? 104001——104999 | ? |
| ? 用戶管理部分自定義錯(cuò)誤 | ? | ? | ? 105001——105999 | ? |
| ? 操作日志管理 | ? | ? | ? 106001——106999 | ? |
?
6.2 補(bǔ)救措施
為了當(dāng)某些故障發(fā)生時(shí)，對(duì)系統(tǒng)進(jìn)行及時(shí)的補(bǔ)救，提供如下補(bǔ)救措施：
a．后備技術(shù)?? 定期對(duì)數(shù)據(jù)庫信息進(jìn)行備份（每天一次），當(dāng)數(shù)據(jù)庫因某種原因被破壞時(shí)，以最新的數(shù)據(jù)庫腳本進(jìn)行恢復(fù)；。
7.????? 系統(tǒng)安全設(shè)計(jì)
7.1 數(shù)據(jù)傳輸安全性設(shè)計(jì)
SSH可以通過將聯(lián)機(jī)的封包加密的技術(shù)進(jìn)行資料的傳遞; 使用SSH可以把傳輸?shù)乃袛?shù)據(jù)進(jìn)行加密，即使有人截獲到數(shù)據(jù)也無法得到有用的信息。同時(shí)數(shù)據(jù)經(jīng)過壓縮，大大地加快了傳輸?shù)乃俣取Ｍㄟ^SSH的使用，可以確保資料傳輸比較安全并且傳輸效率較高。
7.2 應(yīng)用系統(tǒng)安全性設(shè)計(jì)
操作人的操作信息需要提供操作記錄。對(duì)系統(tǒng)的異常信息需進(jìn)行記錄，已備以后查看。只有授權(quán)用戶才能登錄系統(tǒng)，對(duì)于某個(gè)操作，需要具有相應(yīng)權(quán)限才能進(jìn)行操作。
7.3 數(shù)據(jù)存儲(chǔ)安全性設(shè)計(jì)???????????
對(duì)于用戶的密碼等敏感信息采用MD5進(jìn)行加密。
?
OA之權(quán)限管理
權(quán)限管理自己做完了，但是很多的研究和總結(jié)，現(xiàn)在就來總結(jié)一下權(quán)限管理。
第一、數(shù)據(jù)庫中主要類：
主要負(fù)責(zé)類：用戶（User），角色（Role）、資源（module）和操作（Permission）
衍生類：用戶角色（UserRole）和對(duì)某個(gè)資源的某個(gè)操作（ACL）
?
?
第二、ACL的具體理解：
一條acl授權(quán)記錄中主要記錄了以下信息:?角色、資源和授權(quán)?
授權(quán)作為一個(gè)int, 每一位是一個(gè)操作的權(quán)限.?
假設(shè)從右向左, 分別代表CRUD?
那么, 我們CRUD的代碼就應(yīng)該是0123(也就是移位時(shí)要移的位數(shù)), 因?yàn)槲覀円M(jìn)行移位進(jìn)行認(rèn)證。
先看授權(quán)與取消授權(quán)的代碼：
?
[java]?view plaincopy?
首先, 一個(gè)int temp = 1的臨時(shí)變量, aclState為原始授權(quán)狀態(tài)tmp的二進(jìn)制表示是: 00000000 00000000 00000000 00000001?
U對(duì)應(yīng)的代碼是U, 對(duì)應(yīng)的是2.?
將tmp左移2位, temp = tmp < < 2; temp變成:00000000 00000000 00000000 00000100?
假設(shè)原始授權(quán)是aclState=00000000 00000000 00000000 00001010?
當(dāng)變量yes=true時(shí)，為授權(quán)，將temp與aclState求|運(yùn)算，因?yàn)閠emp現(xiàn)在只有他要授權(quán)的位為1，求或運(yùn)算后，
aclState=00000000 00000000 00000000 00001110，這樣就授權(quán)成功
當(dāng)變量yes=false時(shí)，為取消授權(quán)，先將temp取反，即為11111111 11111111 11111111 11111011，
現(xiàn)在只有要取消權(quán)限的位為0，其余全為1，然后與aclState求&運(yùn)算，則除了要取消權(quán)限的位變0，其余的都不變，
即aclState=00000000 00000000 00000000 00001010
再來看認(rèn)證：
?
[java]?view plaincopy?
認(rèn)證更簡單，直接將temp變量與aclState求&，temp為1的位為要驗(yàn)證的權(quán)限，其余全為0，如果aclState的這一位為1，則結(jié)果不為零，即有該權(quán)限；若aclState這一位為0，即沒權(quán)限，則結(jié)果為0，沒有該操作權(quán)限
總結(jié)：權(quán)限管理最難理解的就是CRUD中的數(shù)據(jù)得來，至于別的我們可以關(guān)系，我們還是可以清晰的理解，還有一個(gè)概念就是集成的概念：
?
a)????????針對(duì)某個(gè)資源的所有操作，我們可以設(shè)置這些權(quán)限對(duì)用戶來說是“繼承”或“不繼承”
?
????????????????????????i.?????????????繼承：意思是這些權(quán)限將使用其（即用戶）所擁有的角色的權(quán)限，而不使用其（即用戶）單獨(dú)設(shè)置的權(quán)限
?
??????????????????????ii.?????????????不繼承：意思是這些權(quán)限將使用其單獨(dú)設(shè)置的權(quán)限，而不使用其所擁有的角色的權(quán)限
轉(zhuǎn)載于:https://www.cnblogs.com/taozi32/p/6129719.html
總結(jié)
以上是生活随笔為你收集整理的系统权限管理设计 （转）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 22考研在职跨考软件工程（专业课408）
- 下一篇： 水系图一般在哪里找得到_真空排水系统在综