寫在前面
本系列部落格是本人在學習的過程中搭建學習的記錄，如果對你有所幫助那再好不過。如果您有發現錯誤，請告知我，我會第一時間修改。
前期我不會公開原始碼，我想是一點點敲程式碼，不然複製、貼上那就沒意思了。而且很多程式碼(比如Identity Server4)網上也有很多類似的教程及成熟的框架。這裡只是想，知其然，知其所以然，並非重複的造輪子。因為這段時間我發現，自己悶很久寫出來的程式碼，再去看看別人的，會有種恍然大悟的感覺。不是隻會用，不知道為什麼要這樣用。
真的，只看不敲，總是學不會。
Demo地址：http://app.guoddy.com
資料並不會真實儲存，設定的為測試模式，所以免登入。
本系列文章是計劃做一個通用許可權處理系統，可以在此基礎上去做擴充性開發其實本計劃是繼續增加流程管理和及時通訊的,em...這個後續慢慢增加，流程表單及設計還沒研究透。
記錄內容
總述
1.專案的搭建
2.資料庫設計(許可權模組)
3.EF的使用
4.業務程式碼的實現
5.依賴注入
6.許可權驗證
7.做個登入驗證
資料庫設計(許可權模組)
我先說下我參考的資料，後續是在自己理解的基礎上做些修改。
原文是參考應用程式許可權設計
需求
需求不同，許可權的控制粒度就不同。通常情況下分為三種情況
1.控制當前登入使用者能夠看到的選單。
2.控制當前登入使用者能夠看到的選單，還要控制選單下的操作按鈕。
3.資料和資料列許可權：資料許可權指普通使用者只能看到自己發表的內容，而領導可以看到部門下所有使用者發表的內容;資料列許可權指比如金融系統 ，只有某種領導，才能看到使用者的存款餘額，而普通員工是無許可權檢視的。
我們要實現的是控制到按鈕的粒度。
許可權設計&Why
我這裡主要涉及七個表，四個資料表，三個關聯表。
為什麼這樣設計，我覺得可能這是大多數系統的需求。
1.使用者和角色多對多，一個使用者可以擁有多個角色，不然設計角色就沒有了意義，實際可能一個人身兼數職。
2.可以直接給使用者授予或取消授予某個許可權。這個可能會有人覺得沒必要，所以如果不涉及這個，那就是五個表。但是我這裡保留，因為很多情況下，這是很正常的需求。
3.選單可以無限級別，根據實際需求，修改系統配置引數。
詳細說明
ObjectID、Remark、Status、CreatedBy、CreatedTime、ModifiedBy、ModifiedTime、Sort是預設欄位。
SysUserInfo使用者表
- 如果使用者資料量大的話，實際這個表只需要保留
ObjectID、ULoginName、ULoginPWD就可以了，這樣可以提高速度，沒必要把所有資訊都儲存起來。- 使用者和角色多對多 R_sysUserInfo_sysRole
- 使用者和許可權項多對多(直接授權或禁止) R_UserPermissions
| Name | 說明 | 型別 | 主鍵 |
|---|---|---|---|
| ObjectID | 主鍵 | nvarchar(50) | TRUE |
| ULoginName | 使用者名稱 | nvarchar(20) | |
| ULoginPWD | 密碼 | nvarchar(50) | |
| URealName | 真實姓名 | nvarchar(10) | |
| UTelphone | 電話 | nvarchar(20) | |
| UMobile | 手機號 | nvarchar(11) | |
| UEmail | nvarchar(50) | ||
| UQQ | nvarchar(20) | ||
| UGender | 性別:0-女;1-男;2-保密 | int | |
| UDepID | 所屬部門 | nvarchar(50) | |
| Remark | 備註 | nvarchar(500) | |
| Status | 狀態:0-啟用;1-禁用 | int | |
| CreatedBy | 建立人 | nvarchar(50) | |
| CreatedTime | 建立時間 | datetime | |
| ModifiedBy | 修改人 | nvarchar(50) | |
| ModifiedTime | 修改時間 | datetime | |
| Sort | 排序值 | int |
SysRole角色表
- 對角色的分類，比如管理員、普通使用者等。
- 角色使用者多對多 R_sysUserInfo_sysRole
- 角色許可權多對多 R_RolePermission
| Name | 說明 | 型別 | 主鍵 |
|---|---|---|---|
| ObjectID | 主鍵 | nvarchar(50) | TRUE |
| RName | 角色名稱 | varchar(50) | |
| Remark | 備註 | nvarchar(500) | |
| Status | 狀態:0-啟用;1-禁用 | int | |
| CreatedBy | 建立人 | nvarchar(50) | |
| CreatedTime | 建立時間 | datetime | |
| ModifiedBy | 修改人 | nvarchar(50) | |
| ModifiedTime | 修改時間 | datetime | |
| Sort | 排序值 | int |
SysMenus選單表
- 選單表 是一開始設計好後，改動最多的一個表。後續在開發過程中增加了
IsLast、Hierarchy;去除了MAction- IsLast用來標記是不是最後一級，如果是最後一級我們給自動增加增刪改等預設方法。
- Hierarchy用來標記層級，前面我們說可以做到無限極，但是通常情況下會是三級，所以這個需要根據實際設定系統引數，維護的時候檢查限制即可。
- IsMenuShow是否作為選單顯示，也就是左側選單遞迴的，因為有部分API不需要作為選單顯示，並且授權的方式也會不一樣。
- 選單角色多對多 R_RolePermission
- 選單許可權項一對多
| Name | 說明 | 型別 | 主鍵 |
|---|---|---|---|
| ObjectID | 主鍵 | nvarchar(50) | TRUE |
| MName | 名稱 | nvarchar(100) | |
| MUrl | URL | nvarchar(100) | |
| MArea | 區域 | nvarchar(100) | |
| MController | 控制器 | nvarchar(100) | |
| MIcon | 圖示 | nvarchar(100) | |
| IsLast | 是不是最後一級選單:0-是;1-否 | int | |
| IsMenuShow | 是不是作為選單顯示:0-是;1-否 | int | |
| Remark | 備註 | nvarchar(500) | |
| ParentID | 父ID | nvarchar(50) | |
| Status | 狀態:0-啟用;1-禁用 | int | |
| Hierarchy | 層級 | int | |
| CreatedBy | 建立人 | nvarchar(50) | |
| CreatedTime | 建立時間 | datetime | |
| ModifiedBy | 修改人 | nvarchar(50) | |
| ModifiedTime | 修改時間 | datetime | |
| Sort | 排序值 | int |
SysFunction 選單按鈕表 (選單許可權項表)
- SysFunction一開始我是叫選單按鈕表的，我計劃是查詢、新增編輯刪除、其他許可權這樣控制，但後來發現這樣不好，所以全都分開，每個方法都要記錄。當然為了方便，通用的方法，在增加選單的時候會自動新增上。
- 選單許可權項選單是多對一關係
| Name | 說明 | 型別 | 主鍵 |
|---|---|---|---|
| ObjectID | 主鍵 | nvarchar(50) | TRUE |
| FName | 名稱 | nvarchar(50) | |
| FFunction | 方法 | nvarchar(50) | |
| FIcon | 圖示 | nvarchar(50) | |
| ParentID | 所屬選單 | nvarchar(50) | |
| Remark | 備註 | nvarchar(500) | |
| Status | 狀態:0-啟用;1-禁用 | int | |
| CreatedBy | 建立人 | nvarchar(50) | |
| CreatedTime | 建立時間 | datetime | |
| ModifiedBy | 修改人 | nvarchar(50) | |
| ModifiedTime | 修改時間 | datetime | |
| Sort | 排序值 | int |
R_sysUserInfo_sysRole使用者和角色關聯表，記錄使用者和角色的對應關係。
R_RolePermission 角色選單許可權項關聯表。
比如一個角色有用某選單下的查詢和刪除許可權，那麼這個表應該是具有兩條記錄的。
R_UserPermissions 使用者選單許可權項關聯表。
HavePermission記錄該使用者是 是否有許可權:0-無許可權;1-有許可權
後續處理的時候，要從獲取的許可權記錄中排除直接無許可權的記錄，增加有許可權的。
總結
其實網上很多關於許可權的文章，之前自己再看的時候，總是覺得迷迷糊糊，所以最後打算自己動手做。到做完的時候，才有所理解。我也不知道我這裡敘述的是不是不清楚或者設計的是否合理，如果您覺得有問題，請告知我，我會立即改正！
切勿眼高手低，動手敲，像Power Design我也是第一次用，也是第一次用MarkDown寫部落格。
【如果幫助到你了，俺想要個推薦，嘻嘻】