應用程式許可權設計

2021-08-29 21:22:24 字數 1996 閱讀 6649

我們在開發系統的時候,經常會遇到系統需要許可權控制,而許可權的控制程度不同有不同的設計方案。 1.

基於角色的許可權設計

這種方案是最常見也是比較簡單的方案,不過通常有這種設計已經夠了,所以微軟就設計出這種方案的通用做法,這種方案對於每乙個操作不做控制,只是在程式中根據角色對是否具有操作的許可權進行控制;這裡我們就不做詳述

基於操作的許可權設計

這種模式下每乙個操作都在資料庫中有記錄,使用者是否擁有該操作的許可權也在資料庫中有記錄,結構如下:

但是如果直接使用上面的設計,會導致資料庫中的

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應用也可能被其它應用呼叫,因此也需要宣告呼叫自身所需要的許可權 宣告執行該運用所需要的許可權 通過為元素新增子元素即可為程式本身宣告許可權 宣告呼叫該應用所需的許可權 通過為應用的各元件元素,如元素新增子...