我們在開發系統的時候，經常會遇到系統需要許可權控制，而許可權的控制程度不同有不同的設計方案。 1.
基於角色的許可權設計
這種方案是最常見也是比較簡單的方案，不過通常有這種設計已經夠了，所以微軟就設計出這種方案的通用做法，這種方案對於每乙個操作不做控制，只是在程式中根據角色對是否具有操作的許可權進行控制；這裡我們就不做詳述
2.基於操作的許可權設計
這種模式下每乙個操作都在資料庫中有記錄，使用者是否擁有該操作的許可權也在資料庫中有記錄，結構如下：
但是如果直接使用上面的設計，會導致資料庫中的
useraction
這張表資料量非常大，所以我們需要進一步設計提高效率，請看方案33.
基於角色和操作的許可權設計
如上圖所示，我們在新增了
role
，和roleaction
表，這樣子就可以減少
useraction
中的記錄，並且使設計更靈活一點。
但是這種方案在使用者需求的考驗之下也可能顯得不夠靈活夠用，例如當使用者要求臨時給某位普通員工某操作許可權時，我們就需要新增加一種新的使用者角色，但是這種使用者角色是不必要的，因為它只是一種臨時的角色，如果新增一種角色還需要在收回此普通員工許可權時刪除此角色，我們需要設計一種更合適的結構來滿足使用者對許可權設定的要求。 4.
2,3組合的許可權設計，其結構如下：
我們可以看到在上圖中新增了
useraction
表，使用此表來新增特殊使用者的許可權，改表中有乙個字段
haspermission
可以決定使用者是否有某種操作的許可權，改表中記錄的許可權的優先順序要高於
userrole
中記錄的使用者許可權。這樣在應用程式中我們就需要通過
userrole
和useraction
兩張表中的記錄判斷許可權。
到這兒呢並不算完，有可能使用者還會給出這樣的需求：對於某一種
action
所操作的物件某一些記錄會有許可權，而對於其他的記錄沒有許可權，比如說乙個內容管理系統，對於某一些頻道某個使用者有修改的許可權，而對於另外一些頻道沒有修改的許可權，這時候我們需要設計更複雜的許可權機制。 5.
對於同一種實體（資源）使用者可以對一部分記錄有許可權，而對於另外一些記錄沒有許可權的許可權設計：
對於這樣的需求我們就需要對每一種不同的資源建立一張許可權表，在上圖中對
content
和channel
兩種資源分別建立了
useractioncontent
和useractionchannel
表用來定義使用者對某條記錄是否有許可權；這種設計是可以滿足使用者需求的但是不是很經濟，
useractionchannel
和useractioncontent
中的記錄會很多，而在實際的應用中並非需要記錄所有的記錄的許可權資訊，有時候可能只是一種規則，比如說對於根
channel
什麼級別的人有許可權；這時候呢我們就可以定義些規則來判斷使用者許可權，下面就是這種設計。 6.
涉及資源，許可權和規則的許可權設計
在這種設計下角色的概念已經沒有了，只需要
rule
在程式中的類中定義使用者是否有操作某種物件的許可權。
以上只是分析思路，如果有不對的地方，請大家指正。
應用程式許可權設計
我們在開發系統的時候，經常會遇到系統需要許可權控制，而許可權的控制程度不同有不同的設計方案。1.基於角色的許可權設計 這種方案是最常見也是比較簡單的方案，不過通常有這種設計已經夠了，所以微軟就設計出這種方案的通用做法，這種方案對於每乙個操作不做控制，只是在程式中根據角色對是否具有操作的許可權進行控制...
應用程式許可權設計
我們在開發系統的時候，經常會遇到系統需要許可權控制，而許可權的控制程度不同有不同的設計方案。1.基於角色的許可權設計 這種方案是最常見也是比較簡單的方案，不過通常有這種設計已經夠了，所以微軟就設計出這種方案的通用做法，這種方案對於每乙個操作不做控制，只是在程式中根據角色對是否具有操作的許可權進行控制...
應用程式許可權
1 乙個android應用可能需要許可權才能呼叫android系統的功能 2 乙個android應用也可能被其它應用呼叫，因此也需要宣告呼叫自身所需要的許可權 宣告執行該運用所需要的許可權 通過為元素新增子元素即可為程式本身宣告許可權 宣告呼叫該應用所需的許可權 通過為應用的各元件元素，如元素新增子...