前言
有人說，每個人都是平等的；
也有人說，人生來就是不平等的；
在人類社會中，并沒有絕對的公平，
一件事，并不是所有人都能去做；
一樣物，并不是所有人都能夠擁有。
每個人都有自己的角色，每種角色都有對某種資源的一定權利，或許是擁有，或許只能是遠觀而不可褻玩。
把這種人類社會中如此抽象的事實，提取出來，然后寫成程序，還原本質的工作，就是我們程序員該做的事了。
有了一個這么有范兒的開頭，下面便來談談基于RESTful，如何實現不同的人不同的角色對于不同的資源不同的操作的權限控制。
RESTful簡述
本文是基于RESTful描述的，需要你對這個有初步的了解。
RESTful是什么？
Representational State Transfer，簡稱REST，是Roy Fielding博士在2000年他的博士論文中提出來的一種軟件架構風格。
REST比較重要的點是資源和狀態轉換，
所謂"資源"，就是網絡上的一個實體，或者說是網絡上的一個具體信息。它可以是一段文本、一張圖片、一首歌曲、一種服務，總之就是一個具體的實在。
而"狀態轉換"，則是把對應的HTTP協議里面，四個表示操作方式的動詞分別對應四種基本操作：
- GET，用來瀏覽(browse)資源
- POST，用來新建(create)資源
- PUT，用來更新(update)資源
- DELETE，用來刪除(delete)資源。
資源的分類及操作
清楚了資源的概念，然后再來對資源進行一下分類，我把資源分為下面三類：
- 私人資源 (Personal Source)
- 角色資源 (Roles Source)
- 公共資源 (Public Source)
"私人資源"：是屬于某一個用戶所有的資源，只有用戶本人才能操作，其他用戶不能操作。例如用戶的個人信息、訂單、收貨地址等等。
"角色資源"：與私人資源不同，角色資源范疇更大，一個角色可以對應多個人，也就是一群人。如果給某角色分配了權限，那么只有身為該角色的用戶才能擁有這些權限。例如系統資源只能夠管理員操作，一般用戶不能操作。
"公共資源"：所有人無論角色都能夠訪問并操作的資源。
而對資源的操作，無非就是分為四種：
- 瀏覽 (browse)
- 新增 (create)
- 更新 (update)
- 刪除 (delete)
角色、用戶、權限之間的關系
角色和用戶的概念，自不用多說，大家都懂，但是權限的概念需要提一提。
"權限"，就是資源與操作的一套組合，例如"增加用戶"是一種權限，"刪除用戶"是一種權限，所以對于一種資源所對應的權限有且只有四種。
角色與用戶的關系：一個角色對應一群用戶，一個用戶也可以扮演多個角色，所以它們是多對多的關系。
角色與權限的關系：一個角色擁有一堆權限，一個權限卻只能屬于一個角色，所以它們是一(角色)對多(權限)的關系
權限與用戶的關系：由于一個用戶可以扮演多個角色，一個角色擁有多個權限，所以用戶與權限是間接的多對多關系。
需要注意兩種特別情況：
- 私人資源與用戶的關系，一種私人資源對應的四種權限只能屬于一個用戶，所以這種情況下，用戶和權限是一(用戶)對多(權限)的關系。
- 超級管理員的角色，這個角色是神一般的存在，能無視一切阻礙，對所有資源擁有絕對權限，甭管你是私人資源還是角色資源。
數據庫表的設計
角色、用戶、權限的模型應該怎么樣設計，才能滿足它們之間的關系？
對上圖的一些關鍵字段進行說明：
Source
- name: 資源的名稱，也就是其他模型的名稱，例如：user、role等等。
- identity: 資源的唯一標識，可以像uuid，shortid這些字符串，也可以是model的名稱。
- permissions : 一種資源對應有四種權限，分別對這種資源的browse、create、update、delete
Permission
- source : 該權限對應的資源，也就是Source的某一條記錄的唯一標識
- action ：對應資源的操作，只能是browse、create、update、delete四個之一
- relation：用來標記該權限是屬于私人的，還是角色的，用于OwnerPolicy檢測
- roles: 擁有該權限的角色
Role
- users : 角色所對應的用戶群，一個角色可以對應多個用戶
- permissions: 權限列表，一個角色擁有多項權利
User
- createBy : 該記錄的擁有者，在user標里，一般等于該記錄的唯一標識，這一屬性用于OwnerPolicy的檢測，其他私有資源的模型設計，也需要加上這一字段來標識資源的擁有者。
- roles : 用戶所擁有的角色
策略/過濾器
在sails下稱為策略(Policy)，在java SSH下稱為過濾器(Filter)，無論名稱如何，他們工作原理是大同小異的，主要是在一條HTTP請求訪問一個Controller下的action之前進行檢測。所以在這一層，我們可以自定義一些策略/過濾器來實現權限控制。
為行文方便，下面姑且允許我使用策略這一詞。
**策略 (Policy) **
下面排版順序對應Policy的運行順序
-
SessionAuthPolicy：
檢測用戶是否已經登錄，用戶登錄是進行下面檢測的前提。 -
SourcePolicy：
檢測訪問的資源是否存在，主要檢測Source表的記錄 -
PermissionPolicy：
檢測該用戶所屬的角色，是否有對所訪問資源進行對應操作的權限。 -
OwnerPolicy：
如果所訪問的資源屬于私人資源，則檢測當前用戶是否該資源的擁有者。
如果通過所有policy的檢測，則把請求轉發到目標action。
Sails下的權限控制實現
在Sails下，有一個很方便的套件sails-permissions，集成了一套權限管理的方案，本文也是基于該套件的源碼所引出來的權限管理解決方案。
結語
對程序員最大的挑戰，并不是能否掌握了哪些編程語言，哪些軟件框架，而是對業務和需求的理解，然后在此基礎上，把要點抽象出來，寫成計算機能理解的語言。
最后，希望這篇文章，能夠幫助你對權限管理這一課題增加多一點點理解。
寫作參考
如果本文對您有用
請不要吝嗇你們的Follow與Start
這會大大支持我們繼續創作
「Github」
MZMonster ：@MZMonster
JC_Huang ：@JerryC8080
