說起php的許可權，很多人都容易想起rbac，這裡不多介紹。下面介紹一種通用的許可權設計：

首先我們設定一種場景，我們為一個商城做了一個許可權系統，商城裡有許多店鋪，每個店鋪有店長和店員，商城還有運營助理幫忙管理這些店鋪。

一、基礎表:

店鋪表，這裡只取店鋪的id和name。

選單表，這裡取每個選單的 模組/控制器/方法 和名稱，

角色表，主要用在分配角色的時候，我們約定，level越低許可權等級越高，許可權分配的時候，只能由高等級向下分配。比如:店長可以給

店員分配許可權，但是不能給運營助理和其他店長分配許可權。運營助理可以給店長和店員分配許可權。

二、許可權分配

許可權分配的介面如上圖，這個沒什麼好說的。

許可權分配時，主要要解決的問題是，當前使用者能給哪些使用者分配哪些許可權。我們這裡的設計是:

1、當前使用者只能給等級比自己低（level大於自己）的人分配許可權；

2、當前使用者只能給許可權範圍比自己小或者相同的人分配許可權，比如，2號店的店長只能為2號店的店員分配許可權，不能給1號店的店員分配

3、當前使用者只能分配自己有的許可權，比如，2號店長只有訂單管理的許可權，那他只能分配訂單管理這個選單給店員，不能分配會員資訊給

店員，同理，負責2號3號店的運營助理只能分配2號店給某店長，不能分配1號店給某店長。

上圖是一個分配結果。使用者1是運營助理，負責1號2號店鋪，有1到3所有的選單的許可權。使用者2是2號店店長，有1到3選單的許可權。

Ⅰ、建立許可權：

這時我們登陸使用者2，現在如果要新建使用者，那麼只能建level大於3的使用者，即店員。建立好使用者後，要給這個使用者分配許可權，那麼

店鋪只能分配店鋪2，選單可以從當前使用者有的1，2，3中選擇任意組合的選單。

同時，如果我們登陸使用者1，我們既可以新建店長也可以新建店員，比如這時候沒有1號店的店長，那我們新建一個店長，負責1號店，

同時給他操作1-3選單的許可權。

如上圖，我們新建的兩個使用者。

Ⅱ、修改許可權：

和建立的規則相同，如果我們登陸使用者2，使用者2可以修改使用者3的許可權，但是他不能修改使用者3的店鋪，只能修改使用者3的選單許可權（rule），

比如從1,2,修改成2,3。

但是如果我們登陸使用者1，他就可以修改使用者2-4的許可權，比如他可以修改使用者3的store到1，選單不變，那麼此時使用者3就是1號店的店員了。

三、許可權驗證

許可權建立好了，接下來就是如何驗證許可權了。

Ⅰ、結果顯示：

所謂結果顯示，就是當前使用者只能看到當前使用者有許可權的選單。比如，上表中的3號使用者，他只能看到選單1和2，同時，選單1是會員資訊，那麼

他只能看到2號店鋪的會員資訊。這個很簡單，只需要資料庫關聯查詢就可以了。但是在這裡我建議，單獨封裝一個方法來獲取使用者的許可權。

這樣的好處就是修改的時候可以統一修改。比如我這裡有個fuction，就是從資料庫把rule取出來。但是如果需求改變了，不準任何使用者操作1號菜

單。那麼這時候你只需要在這個function裡把結果中的1去掉就好了，而不需要每個地方都去改。

Ⅱ、許可權驗證：

結果顯示只能說防君子不防小人，因為就算你隱藏了，也可以通過url來訪問。比如你的url /store/store_id/1 表示訪問1號店鋪，這時候，就算你的在介面上

隱藏了2號店鋪，但是我依舊可以通過  /store/store_id/2訪問。所以許可權控制需要在控制器裡進行攔截。這時候一般是把許可權驗證放在基類的建構函式中。

phper要注意php不會主動執行父類建構函式的問題，然後其他的控制器繼承這個基類（基礎控制器）。

那麼在使用者訪問一個方法的時候，首先驗證這個使用者是否有訪問當前方法的許可權，有則通過，沒有則報錯。例如上表中的使用者3，他有訪問選單1和2的

許可權，也就是Admin/Base/member和Admin/Base/order。那此時他訪問Admin/Base/goods方法，就應該到報錯介面。

同樣，我們規定對店鋪的訪問key必須是store_id，那麼就可以獲取store_id的引數，如果是2，則使用者3可以訪問，反之如果是其他的，則報錯。同樣，

我們統一商品的必須用good_id表示，那麼我們獲取good_id的id，如果他屬於店鋪2，則使用者3可以訪問，反之拒絕。

以上，一個簡單的B2B2C的許可權系統就完成了，當然，許可權系統一般都和具體的業務和需求結合得比較緊密，大家在實際設計時可以進行相應的限制或者

拓展。