本文我們將討論的是ASPNET MVC Membership權限的設置以及其他的一些問題希望能幫助大家更好的應用ASPNET MVC令開發更快樂
以前一位同事習慣於使用Membership來進行權限管理現在隨著ASPNET MVC的引入采用以前的方法提出了以下方案
ASPNET MVC+Membership結合通過在nfig中進行配置來管理系統中的權限
於是我對這個方案的可行性進行了分析提出了以下疑點
在ASPNET 的Membership中 在nfig中是通過物理文件和目錄那麼在ASPNET MVC中如果在URL中直接輸入物理文件和目錄是找不到這個文件的不知道這種方式還能不能奏效如果說不管在mvc中通過URL Routing怎麼繞最終都會定位到物理文件和目錄上這種方式是行得通的如果不是文件目錄結構的話nfig這種配置是否還能用？關於我提出的這個疑點當時我覺得非常的有趣為了驗證我的疑點於是我做了一個測試
經過一個簡單的Demo測試結果出來了測試結果如下
在ASPNET MVC的Membership中並不是基於文件和目錄的而是易於URLRouting的當進行文件目錄配置的話是不起作用的只有在nfig中進行URLRouting的權限配置才會起作用最終經過測試如果按照默認路由走的話最終也是可以通過配置進行權限的控制只不過是配置起來的話要把文件路徑改為controller/action而不是原來的Controller/Actionaspx
接下來再想一想這樣會不會有什麼問題？
以往的Webform開發url是穩定因素（URL重寫除外）所以通過Membership進行權限設定是沒有問題的但是在MVC中URL是不穩定因素如果更改了routing設置權限系統就會被繞過去從模塊職責上來說不應該因為其它模塊的更改導致權限管理模塊失效這從設計上就是一個糟糕的設計所以從個人情感上來說我認為這種設計糟糕透了既然URL是不穩定因素不應該通過這個來進行權限控制也就是說不應該通過不穩定因素來參雜權限管理 URL是不穩定的那麼較穩定的因素應該就是Controller跟Action也就是說無論URL怎麼變最終都可以把Controller跟Action確定下來因此在ASPNET MVC中應該通過Controller跟Action結合來進行權限控制了解URLRouting的朋友們一定知道MVC中的路由是按照順序執行的如果滿足了前面的匹配規則將不會執行後面的匹配規則稍稍對於URLRouting掌握不好就會給系統的安全帶來隱患
權限系統一般分為穩定不變的部分較穩定的部分不穩定部分因此在進行權限系統的時候就應當綜合考慮這些因素
關於權限系統的設計一般都會按照如下來設計
抽象出系統中的實體部分（系統中穩定不變的部分或系統中較穩定的部分） 將抽象的實體部分進行抽象設計（實體類）設計實體類之間的存儲
分析實體類之間的關系這些是系統中不穩定的部分因此要將這些關系進行存儲（存儲在數據庫中或配置文件中方便以後進行修改）經過如上的設計一般來說當權限管理系統達到如下要求就算是合格了
能完成基本的權限管理當需要進行權限管理的時候整個權限系統的架構不變變的僅僅是數據一個合格的權限系統的設計通常不夠完美所以需要結合實際情況綜合考慮進行改進至於如何改進沒有統一的方法可言
關於Membership很多人都喜歡重用Membership的一些東西可是究竟能夠重用的部分有多少？
ASPNET 中提供的控件如 LoginLoginViewPasswordRecoveryCreateUserWizardChangePassword等當然這些並不是Membership的部分但是這些通常都會跟Membership配合使用這些控件提供了方便的開發可是通常這些控件並不能滿足要求擴展性並不好而且這些控件會生成很多垃圾代碼如jscss等在帶來開發方便的同時也給擴展跟維護帶來不便最重要的一點凡是涉及Postback的控件在ASPNET MVC中全部不能使用
數據庫及數據庫訪問通過執行aspnet_regsql命令可以自動在數據庫中創建出張表並且提供了若干個API方法來對這張表進行操作可是這張表中的設計往往也是不符合要求的如果進行擴展的話就會比較麻煩一般擴展的方法有兩種不改變原來的表但是要建一張表跟以前的表對應表中的Id跟原來表中一模一樣改變原來表的設計無論是哪種方法數據庫訪問部分就必須得重寫因此數據庫及數據庫訪問的重用也變的非常低基於配置文件的權限控制似乎從目前上來看能重用的部分只有這個了可是在ASPNET MVC中URL是個不穩定因素基於配置文件的權限控制這個功能的重用並不適合ASPNET MVC的開發綜合對比一下至少在ASPNET MVC開發中Membership所帶來的重用微乎其微
在不同的權限管理系統中對控制級別的要求是不一樣的如頁面訪問級別數據訪問級別控件訪問級別函數級別可是不論是要控制到那個級別權限管理系統所要完成的功能都是一樣的 我們不妨給權限管理系統下一個定義權限管理系統就是告訴其它模塊用戶/角色對特定的資源/功能是否具有訪問的權限
在Webform中用戶跟角色相比角色是不穩定因素用戶是相對較穩定的因素因此權限系統的輸入參數中我們通常會傳入用戶而不輸入角色因為角色是不穩定的至於說用戶屬於哪個角色權限系統是可以查出來的
而在ASPNET MVC中用戶跟角色都可以是較穩定因素因為用戶的權限控制跟角色的權限控制都是通過擴展標記屬性來實現的這是跟webform相比權限系統設計上不一樣的地方
ASPNET MVC中權限控制是通過對Action的攔截實現的實現的方式如下
定義一個擴展屬性標記類繼承自接口IActionFilter的抽象類ActionFilterAttribute重寫ActionFilterAttribute中的虛方法將擴展標記作用於Controller跟Action關於ASPNET MVC中的權限管理方案網上已經有了這裡就不過多的贅述了
From:http://tw.wingwit.com/Article/program/net/201311/11521.html
