ASP.NET MVC Membership 許可權 漫談

以前一位同事習慣於使用Membership來進行許可權管理，現在隨著ASP.NET MVC的引入，採用以前的方法，提出了以下方案：

ASP.NET MVC+Membership結合，通過在web.config中進行配置，來管理系統中的許可權。

於是，我對這個方案的可行性進行了分析，提出了以下疑點：

1. 在ASP.NET 2.0的Membership中， 在Web.config中是通過物理檔案和目錄，那麼在ASP.NET MVC中，如果在URL中直接輸入物理檔案和目錄，是找不到這個檔案的，不知道這種方式還能不能奏效。如果說不管在mvc中，通過URL Routing怎麼繞，最終都會定位到物理檔案和目錄上，這種方式是行得通的。
2. 如果不是檔案目錄結構的話，web.config這種配置是否還能用？

關於我提出的這個疑點，當時我覺得非常的有趣。為了驗證我的疑點，於是我做了一個測試。

經過一個簡單的Demo，測試結果出來了。測試結果如下：

1.  在ASP.NET MVC的Membership中，並不是基於檔案和目錄的，而是易於URLRouting的，當進行檔案目錄配置的話，是不起作用的，只有在web.config中進行URLRouting的許可權配置才會起作用。

最終經過測試，如果按照預設路由走的話，最終也是可以通過配置進行許可權的控制。只不過是配置起來的話，要把檔案路徑改為“controller/action”而不是原來的“Controller/Action.aspx”。

 

接下來再想一想，這樣會不會有什麼問題？

1.  以往的Webform開發，url是穩定因素（URL重寫除外），所以，通過Membership進行許可權設定是沒有問題的。但是在MVC中，URL是不穩定因素，如果更改了routing設定，許可權系統就會被繞過去。從模組職責上來說，不應該因為其它模組的更改，導致許可權管理模組失效，這從設計上就是一個糟糕的設計。所以，從個人情感上來說，我認為這種設計糟糕透了。
2. 既然URL是不穩定因素，不應該通過這個來進行許可權控制，也就是說不應該通過不穩定因素來參雜許可權管理。
3. URL是不穩定的，那麼較穩定的因素應該就是Controller跟Action，也就是說，無論URL怎麼變，最終都可以把Controller跟Action確定下來。因此，在ASP.NET MVC中，應該通過Controller跟Action結合來進行許可權控制。
4. 瞭解URLRouting的朋友們一定知道，MVC中的路由是按照順序執行的，如果滿足了前面的匹配規則，將不會執行後面的匹配規則，稍稍對於URLRouting掌握不好，就會給系統的安全帶來隱患。

許可權系統一般分為：穩定不變的部分、較穩定的部分、不穩定部分。因此在進行許可權系統的時候就應當綜合考慮這些因素。

關於許可權系統的設計，一般都會按照如下來設計：

1. 抽象出系統中的實體部分（系統中穩定不變的部分或系統中較穩定的部分）。
2.  將抽象的實體部分進行抽象設計（實體類）。
3. 設計實體類之間的儲存。
4. 分析實體類之間的關係，這些是系統中不穩定的部分，因此要將這些關係進行儲存（儲存在資料庫中或設定檔中，方便以後進行修改）。

經過如上的設計，一般來說當許可權管理系統達到如下要求就算是合格了：

1. 能完成基本的許可權管理
2. 當需要進行許可權管理的時候，整個許可權系統的架構不變，變的僅僅是資料。

一個合格的許可權系統的設計通常不夠完美，所以需要結合實際情況綜合考慮進行改進。至於如何改進，沒有統一的方法可言。

關於Membership，很多人都喜歡重用Membership的一些東西，可是究竟能夠重用的部分有多少？

1. ASP.NET 2.0中提供的控制項，如： Login、LoginView、PasswordRecovery、CreateUserWizard、ChangePassword等，當然，這些並不是Membership的部分，但是這些通常都會跟Membership配合使用。這些控制項提供了方便的開發，可是通常這些控制項並不能滿足要求，擴充性並不好，而且這些控制項會產生很多垃圾代碼如：js、css等。在帶來開發方便的同時，也給擴充跟維護帶來不便。最重要的一點，凡是涉及Postback的控制項，在ASP.NET MVC中，全部不能使用。
2. 資料庫及資料庫訪問。通過執行“aspnet_regsql”命令，可以自動在資料庫中建立出11張表，並且提供了若干個API方法來對這11張表進行操作。可是這11張表中的設計往往也是不符合要求的，如果進行擴充的話，就會比較麻煩。一般擴充的方法有兩種：不改變原來的表，但是要建一張表跟以前的表對應，表中的Id跟原來表中一模一樣；改變原來表的設計。無論是哪種方法，資料庫訪問部分就必須得重寫，因此資料庫及資料庫訪問的重用也變的非常低。
3. 基於設定檔的許可權控制，似乎從目前上來看，能重用的部分只有這個了。可是在ASP.NET MVC中URL是個不穩定因素，基於設定檔的許可權控制這個功能的重用並不適合ASP.NET MVC的開發。

綜合對比一下，至少在ASP.NET MVC開發中，Membership所帶來的重用微乎其微。

 

在不同的許可權管理系統中，對控制層級的要求是不一樣的，如：頁面存取層級、資料存取層級、控制項存取層級、函數層級。。。。。。可是不論是要控制到那個層級，許可權管理系統所要完成的功能都是一樣的 。我們不妨給許可權管理系統下一個定義：許可權管理系統就是告訴其它模組使用者/角色對特定的資源/功能是否具有訪問的許可權。

在Webform中，使用者跟角色相比，角色是不穩定因素，使用者是相對較穩定的因素。因此許可權系統的輸入參數中我們通常會傳入使用者，而不輸入角色，因為角色是不穩定的，至於說使用者屬於哪個角色，許可權系統是可以查出來的。

而在ASP.NET MVC中，使用者跟角色都可以是較穩定因素，因為使用者的許可權控制跟角色的許可權控制都是通過擴充標記屬性來實現的。這是跟webform相比，許可權系統設計上不一樣的地方。

 

ASP.NET MVC中許可權控制是通過對Action的攔截實現的。實現的方式如下：

1. 定義一個擴充屬性標記類，繼承自介面IActionFilter的抽象類別ActionFilterAttribute。
2. 重寫ActionFilterAttribute中的虛方法。
3. 將擴充標記作用於Controller跟Action。

關於ASP.NET MVC中的許可權管理方案，網上已經有了，這裡就不過多的贅述了。

 

以下是我前段時間設計的許可權管理系統的類別關係圖，只完成了部分的設計，還有個別部分沒有加上， 是使用PowerDesigner 15設計的，由於這段時間非常的忙，沒有繼續完成剩下的功能。如果以後有時間，我會完成剩下的設計，然後重新上傳。

許可權管理系統類別關係圖