1. 程式人生 > >系統設計——許可權系統

系統設計——許可權系統

前言:寫了兩篇關於DataGridView的文章:Winform系列——好用的DataGridview過濾控制元件(表格的高階搜尋功能) 和 Winform系列——好看的DataGridView摺疊控制元件。這章來記錄下許可權系統。關於許可權系統,網上版本非常多,大都實用性不太高,大多數的系統就是因為分得太細了反而使系統錯綜複雜,甚至有看到有按照角色、部門、地區、使用者四個方便分別去做許可權分配的,我的個神,這樣一來,要取一個使用者的許可權那個麻煩,當然並非說那些大神們封的東西不好,而是適用性的問題,對於某些大型公司的系統,對許可權要求確實有那麼高也說不定,但其實根據本人工作幾年的經驗來看,大部分的.Net系統其實對許可權的要求並沒有想象中的那麼高。在這裡記錄下自己從頭到尾設計和開發的一個許可權系統,個人覺得對於基本的許可權分配夠用了。

1、系統介紹:說是系統,其實許可權只是系統的一個模組,此係統主要就是根據角色來分配許可權的,通過角色分別控制使用者的選單許可權和選單對應頁面的按鈕許可權。

2、資料表設計:

 (1)上圖

   (2)表的DDL語句:

/*==============================================================*/
/* DBMS name:      ORACLE Version 11g                           */
/* Created on:     2015/6/15 11:55:21                           
*/ /*==============================================================*/ alter table TB_MenuRole drop constraint FK_TB_MENUR_REFERENCE_TB_ROLE; alter table TB_MenuRole drop constraint FK_TB_MENUR_REFERENCE_TB_MENU; alter table TB_UserRole drop constraint FK_TB_USERR_REFERENCE_TB_USERS;
alter table TB_UserRole drop constraint FK_TB_USERR_REFERENCE_TB_ROLE; alter table TB_Users drop constraint FK_TB_USERS_REFERENCE_TB_DEPAR; drop table TB_Department cascade constraints; drop table TB_Menu cascade constraints; drop table TB_MenuRole cascade constraints; drop table TB_Role cascade constraints; drop table TB_UserRole cascade constraints; drop table TB_Users cascade constraints; /*==============================================================*/ /* Table: "TB_Department" */ /*==============================================================*/ create table TB_Department ( department_id VARCHAR(50) not null, department_name VARCHAR(50), parent_id VARCHAR(50), department_level VARCHAR(10), status VARCHAR(10), constraint PK_TB_DEPARTMENT primary key (department_id) ); /*==============================================================*/ /* Table: "TB_Menu" */ /*==============================================================*/ create table TB_Menu ( menu_id VARCHAR(50) not null, menu_name VARCHAR(50), menu_url VARCHAR(50), parent_id VARCHAR(50), menu_level VARCHAR(10), sort_order VARCHAR(50), status VARCHAR(10), remark VARCHAR(1000), constraint PK_TB_MENU primary key (menu_id) ); /*==============================================================*/ /* Table: "TB_MenuRole" */ /*==============================================================*/ create table TB_MenuRole ( id VARCHAR(50) not null, role_id VARCHAR(50), menu_id VARCHAR(50), role_type VARCHAR(10), button_id VARCHAR(50), constraint PK_TB_MENUROLE primary key (id) ); /*==============================================================*/ /* Table: "TB_Role" */ /*==============================================================*/ create table TB_Role ( role_id VARCHAR(50) not null, role_name VARCHAR(50), description VARCHAR(500), createtime DATE, modifytime DATE, constraint PK_TB_ROLE primary key (role_id) ); /*==============================================================*/ /* Table: "TB_UserRole" */ /*==============================================================*/ create table TB_UserRole ( id VARCHAR(50) not null, role_id VARCHAR(50), user_id VARCHAR(50), constraint PK_TB_USERROLE primary key (id) ); /*==============================================================*/ /* Table: "TB_Users" */ /*==============================================================*/ create table TB_Users ( user_id VARCHAR(50) not null, user_name VARCHAR(50), user_password VARCHAR(50), fullname VARCHAR(50), department_id VARCHAR(50), status VARCHAR(10), createtime DATE, modifytime DATE, remark VARCHAR(1000), constraint PK_TB_USERS primary key (user_id) ); comment on table TB_Users is '使用者資訊表'; alter table TB_MenuRole add constraint FK_TB_MENUR_REFERENCE_TB_ROLE foreign key (role_id) references TB_Role (role_id); alter table TB_MenuRole add constraint FK_TB_MENUR_REFERENCE_TB_MENU foreign key (menu_id) references TB_Menu (menu_id); alter table TB_UserRole add constraint FK_TB_USERR_REFERENCE_TB_USERS foreign key (user_id) references TB_Users (user_id); alter table TB_UserRole add constraint FK_TB_USERR_REFERENCE_TB_ROLE foreign key (role_id) references TB_Role (role_id); alter table TB_Users add constraint FK_TB_USERS_REFERENCE_TB_DEPAR foreign key (department_id) references TB_Department (department_id);
View Code

   (3) 表說明:許可權模組總共就6張表,即部門表、使用者表、角色表、使用者角色表、選單表、選單角色表(包含按鈕許可權)。使用者表和角色表之間的關係是通用的多對多的關係,沒什麼好說的。看看TB_MenuRole表,這個表用來儲存角色的選單許可權和按鈕許可權,其中role_type取值為menu和button,如果是menu,則此行記錄用於儲存選單許可權,button_id為空;如果是button,則此行記錄用於儲存選單下的某一個按鈕的許可權,menu_id為按鈕所在的選單id,button_id為對應的按鈕id。還有一個問題就是按鈕的id從哪裡來?是否還應該有一個儲存按鈕ID的表呢?答案是不需要,後面會介紹。

3、效果圖:先做的是一個CS的系統,後續還會做BS的。

3.1 許可權模組主要分為4大頁面:使用者管理、角色管理、部門管理和選單管理

3.2 使用者管理頁面:

“設定角色”操作:

3.3 角色管理頁面:

“編輯許可權”操作:

在“編輯許可權”彈出框中點選“設定按鈕操作”

角色管理頁面的“管理成員”操作:

可以新增當前角色的使用者,點選“新增”

3.4 部門管理頁面:

3.5 選單管理頁面:

4、後臺業務邏輯都是簡單的增刪改查,沒什麼好說的。前面說的關於按鈕ID是否需要一張按鈕表的問題,我們系統在處理方式是

在點選設定按操作的時候傳遞一個選單url,然後在程式碼裡面通過反射得到所有的按鈕,然後勾選按鈕後儲存到資料庫。注意一個頁面的按鈕的ID不會重複,所以通過這樣可以取到唯一的按鈕,而在資料表TB_MenuRole中儲存的如果是按鈕許可權,是有儲存Menu_Id的,所以不必擔心不同頁面的問題。這樣設計的好處是當程式設計師在頁面上面新增刪除按鈕後不用修改配置,通過反射即可載入頁面的即時按鈕個數。純屬個人設計,如果有問題,歡迎大俠們指正。

相關推薦

系統設計——許可權系統

前言:寫了兩篇關於DataGridView的文章:Winform系列——好用的DataGridview過濾控制元件(表格的高階搜尋功能) 和 Winform系列——好看的DataGridView摺疊控制元件。這章來記錄下許可權系統。關於許可權系統,網上版本非常多,大都實用性不太高,大多數的系統就是因為分得太細

如何設計許可權系統

談到許可權控制的設計,需要先理清楚定義和原理。 所以我們需要看到許可權控制中,控制的本質,也就是說控制的是什麼? 其實是:使用者與可以進行的行為的關聯關係。 這句話中有3個關鍵詞:使用者、行為、關聯關係。 衍生出如下幾個問題 關於使用者 使用者是怎麼分類的(使用者角色)使用者和使用者之間是否有關係?如果有,

一些系統設計系統開發的感悟

比較 開發人員 tex 是什麽 三種 ima 很多 歸納 acf 最近沒啥產出,心態不太好,想寫的很多,但博客更新的比較少。今天談談系統設計的感悟吧(雖然也沒設計過NB的系統)。做出一個系統和做功能是不同的,考慮的因素也不相同。相對來說,功能開發比較簡單,系統設計考慮的內容

找java設計,基於ssh,j2ee管理系統,設計,管理系統設計思路與技巧

ava 畢設 框架 僅供參考 andro 培訓 中一 畢業 遠程 關於基於ssh,ssm,javaee等等管理系統的設計思路與框架搭建,很多同學都是一知半解,甚至是知之甚少。為了大家能快速的開發設計一套這樣的java設計,我們提供下面的一些方法僅供參考。不足之處大家可以相互

整理下最近OA系統許可權系統書寫過程中的部分收穫

一.業務開發中的各類註解   1.lombok包下的實體類註解包括@Data,@AllArgsConstructor,@NoArgsConstructor,提供了get,set,toString,全參構造和無參構造的方法。 2.javax.persistence下的@entit

我的許可權系統設計實現MVC4 WebAPI EasyUI Knockout 一

分享一下我老師大神的人工智慧教程!零基礎,通俗易懂!http://blog.csdn.net/jiangjunshow 也歡迎大家轉載本篇文章。分享知識,造福人民,實現我們中華民族偉大復興!        

許可權系統設計-day01

資料庫表的設計:   關鍵流程思考: 許可權在SSH系統中應該表現為什麼東西?     小胖這個使用者登陸:1,檢查使用者名稱和密碼;2,檢查通過;   1),得到小胖這個使用者的對應的所有的角色:R1   2),根據所有的角色,得到小胖所有的

許可權系統設計-day02

練習中的問題: 1,<s:url action="employee_input" />這個標籤用來讓struts自動生成請求的路徑,struts生成的路徑是一個全路徑,包含了context/package/action_method.action   1),context:就是我們在tomcat

許可權系統設計模式 ACL RBAC ABAC

ACL(Access Control List):訪問許可權列表  如:   user1-->AC1 user1-->AC2 user2-->AC1    此時許可權彙總成一個列表 這種設計最常見的應用就是檔案系統的許可權

通用使用者許可權系統設計

今天暫時就看許可權管理系統的資料庫表設計吧。 子系統表,因為我這裡設計的為了能夠整合公司內部以後所有的系統的,所以建了子系統這張表,如果單個專案,這張表可以去掉。 模組表,系統中的各個模組。 模組功能表,模組中的各個功能(可以有兩種功能,一種是頁面的進入許可權,一種是頁面上的按鈕事件) 使用者表 角色表 使用

資料庫篇(資料庫設計) ---許可權系統設計

目錄 概述 使用者-許可權 概述     許可權管理,一般指根據系統設定的安全規則或者安全策略,使用者可以訪問而且只能訪問自己被授權的資源,不多不少。     許可權管理幾乎出現在任何系統裡面,只要有使用者和密碼的系統。 很多人常將“使用者身份認證”

經典許可權系統設計(五張表)

大致用到5張表:使用者表(UserInfo)、角色表(RoleInfo)、選單表(MenuInfo)、使用者角色表(UserRole)、角色選單表(RoleMenu)。   各表的大體表結構如下:   1、使用者表(UserInfo):Id、UserName、UserPwd

許可權系統設計學習總結(1)——多租戶的RBAC許可權管理

一、公司(Company)   公司包含了體系結構集合與使用者集合。 公司可以存在上下級關係,這種關係僅限於展現形式,公司與公司之間沒有許可權繼承,也就是說在授權管理中公司之間全部是扁平關係。公司的屬性有以下內容: 屬性 型別 公司編碼 字串 公司名稱

基於RBAC模型的許可權系統設計(Github開源專案)

計劃在Team的Github開源專案里加入許可權控制的業務功能。從而實現許可權控制。在很多管理系統裡都是有許可權管理這些通用模組的,當然在企業專案裡,許可權控制是很繁雜的。 Team的Github開源

經典角色許可權系統設計五張表及拓展應用

設計基礎:使用者、角色、許可權三大核心表,加上使用者角色、角色許可權兩個對映表(用於給使用者表聯絡上許可權表)。這樣就可以通過登入的使用者來獲取許可權列表,或判斷是否擁有某個許可權。   大致用到5張表:使用者表(UserInfo)、角色表(RoleInfo)、

後臺許可權管理系統設計(圖文教程)

後臺許可權管理系統設計(圖文教程) 作者:橘子洲頭 全文共 2210 字 5 圖,閱讀需要 6 分鐘 參考:原文連結 ———————— / BEGIN / ———————— 在人人都是產品經理的網站上蟄居了4年,學習了四年,由於最近的工

後臺經驗分享:如何做許可權管理系統設計

作者:橘子洲頭 全文共 2210 字 5 圖,閱讀需要 6 分鐘 ———— / BEGIN / ———— 在人人都是產品經理的網站上蟄居了4年,學習了四年,由於最近的工作方向偏向於後臺,在設計後臺時時常會查閱後臺的相關資料,但是關於後臺的文章等內容分享的太少了。 正好這一段時間在調整,想嘗試撰寫一系

架構設計分享之許可權系統(看圖說話)

前面一篇文章《最近架構隨想》,我提到架構設計的一些構想,其實也是對之前專案經驗的一些歸納及總結。今天我們就以許可權系統作為切入點,談一談怎麼設計許可權系統以及怎麼做到系統具有以下特性: Organized:如果系統組織比較好,可以起到事半功倍的效果。 Encapsulated:對功能,結構,資料進行有

許可權管理系統 設計思路

有興趣可以瞭解下這款國內人氣很旺的JAVA程式碼生成器基於拖拽,不用寫複雜的模板,支援多種資料庫,適配wap,管理後臺各種功能全有 免費開源 地址:https://blog.csdn.net/adyuebanwan/article/details/83006405 或者 ht

基於角色的許可權管理系統設計思路

概述 許可權管理功能是專案中重要的部分,通過許可權系統可以控制系統中各使用者所擁有的許可權,比如能否開啟一個頁面,能否進行某項操作,合理的許可權控制可以規避誤操作的風險,提高系統的可用性。 許可權管理的思路一般為基於角色和基於資源兩種,基於角色即對為使用者賦