新聞中心
本文我們將討論的是ASP.NET MVC Membership權(quán)限的設(shè)置,以及其他的一些問題。希望能幫助大家更好的應(yīng)用ASP.NET MVC,令開發(fā)更快樂。

#T#
以前一位同事習(xí)慣于使用Membership來進(jìn)行權(quán)限管理,現(xiàn)在隨著ASP.NET MVC的引入,采用以前的方法,提出了以下方案:
ASP.NET MVC+Membership結(jié)合,通過在web.config中進(jìn)行配置,來管理系統(tǒng)中的權(quán)限。
于是,我對這個方案的可行性進(jìn)行了分析,提出了以下疑點:
在ASP.NET 2.0的Membership中, 在Web.config中是通過物理文件和目錄,那么在ASP.NET MVC中,如果在URL中直接輸入物理文件和目錄,是找不到這個文件的,不知道這種方式還能不能奏效。如果說不管在mvc中,通過URL Routing怎么繞,最終都會定位到物理文件和目錄上,這種方式是行得通的。如果不是文件目錄結(jié)構(gòu)的話,web.config這種配置是否還能用?關(guān)于我提出的這個疑點,當(dāng)時我覺得非常的有趣。為了驗證我的疑點,于是我做了一個測試。
經(jīng)過一個簡單的Demo,測試結(jié)果出來了。測試結(jié)果如下:
在ASP.NET MVC的Membership中,并不是基于文件和目錄的,而是易于URLRouting的,當(dāng)進(jìn)行文件目錄配置的話,是不起作用的,只有在web.config中進(jìn)行URLRouting的權(quán)限配置才會起作用。最終經(jīng)過測試,如果按照默認(rèn)路由走的話,最終也是可以通過配置進(jìn)行權(quán)限的控制。只不過是配置起來的話,要把文件路徑改為“controller/action”而不是原來的“Controller/Action.aspx”。
接下來再想一想,這樣會不會有什么問題?
以往的Webform開發(fā),url是穩(wěn)定因素(URL重寫除外),所以,通過Membership進(jìn)行權(quán)限設(shè)定是沒有問題的。但是在MVC中,URL是不穩(wěn)定因素,如果更改了routing設(shè)置,權(quán)限系統(tǒng)就會被繞過去。從模塊職責(zé)上來說,不應(yīng)該因為其它模塊的更改,導(dǎo)致權(quán)限管理模塊失效,這從設(shè)計上就是一個糟糕的設(shè)計。所以,從個人情感上來說,我認(rèn)為這種設(shè)計糟糕透了。既然URL是不穩(wěn)定因素,不應(yīng)該通過這個來進(jìn)行權(quán)限控制,也就是說不應(yīng)該通過不穩(wěn)定因素來參雜權(quán)限管理。 URL是不穩(wěn)定的,那么較穩(wěn)定的因素應(yīng)該就是Controller跟Action,也就是說,無論URL怎么變,最終都可以把Controller跟Action確定下來。因此,在ASP.NET MVC中,應(yīng)該通過Controller跟Action結(jié)合來進(jìn)行權(quán)限控制。了解URLRouting的朋友們一定知道,MVC中的路由是按照順序執(zhí)行的,如果滿足了前面的匹配規(guī)則,將不會執(zhí)行后面的匹配規(guī)則,稍稍對于URLRouting掌握不好,就會給系統(tǒng)的安全帶來隱患。
權(quán)限系統(tǒng)一般分為:穩(wěn)定不變的部分、較穩(wěn)定的部分、不穩(wěn)定部分。因此在進(jìn)行權(quán)限系統(tǒng)的時候就應(yīng)當(dāng)綜合考慮這些因素。
關(guān)于權(quán)限系統(tǒng)的設(shè)計,一般都會按照如下來設(shè)計:
抽象出系統(tǒng)中的實體部分(系統(tǒng)中穩(wěn)定不變的部分或系統(tǒng)中較穩(wěn)定的部分)。 將抽象的實體部分進(jìn)行抽象設(shè)計(實體類)。設(shè)計實體類之間的存儲。
分析實體類之間的關(guān)系,這些是系統(tǒng)中不穩(wěn)定的部分,因此要將這些關(guān)系進(jìn)行存儲(存儲在數(shù)據(jù)庫中或配置文件中,方便以后進(jìn)行修改)。經(jīng)過如上的設(shè)計,一般來說當(dāng)權(quán)限管理系統(tǒng)達(dá)到如下要求就算是合格了:
能完成基本的權(quán)限管理當(dāng)需要進(jìn)行權(quán)限管理的時候,整個權(quán)限系統(tǒng)的架構(gòu)不變,變的僅僅是數(shù)據(jù)。一個合格的權(quán)限系統(tǒng)的設(shè)計通常不夠***,所以需要結(jié)合實際情況綜合考慮進(jìn)行改進(jìn)。至于如何改進(jìn),沒有統(tǒng)一的方法可言。
關(guān)于Membership,很多人都喜歡重用Membership的一些東西,可是究竟能夠重用的部分有多少?
ASP.NET 2.0中提供的控件,如: Login、LoginView、PasswordRecovery、CreateUserWizard、ChangePassword等,當(dāng)然,這些并不是Membership的部分,但是這些通常都會跟Membership配合使用。這些控件提供了方便的開發(fā),可是通常這些控件并不能滿足要求,擴(kuò)展性并不好,而且這些控件會生成很多垃圾代碼如:js、css等。在帶來開發(fā)方便的同時,也給擴(kuò)展跟維護(hù)帶來不便。最重要的一點,凡是涉及Postback的控件,在ASP.NET MVC中,全部不能使用。
數(shù)據(jù)庫及數(shù)據(jù)庫訪問。通過執(zhí)行“aspnet_regsql”命令,可以自動在數(shù)據(jù)庫中創(chuàng)建出11張表,并且提供了若干個API方法來對這11張表進(jìn)行操作??墒沁@11張表中的設(shè)計往往也是不符合要求的,如果進(jìn)行擴(kuò)展的話,就會比較麻煩。一般擴(kuò)展的方法有兩種:不改變原來的表,但是要建一張表跟以前的表對應(yīng),表中的Id跟原來表中一模一樣;改變原來表的設(shè)計。無論是哪種方法,數(shù)據(jù)庫訪問部分就必須得重寫,因此數(shù)據(jù)庫及數(shù)據(jù)庫訪問的重用也變的非常低?;谂渲梦募臋?quán)限控制,似乎從目前上來看,能重用的部分只有這個了??墒窃贏SP.NET MVC中URL是個不穩(wěn)定因素,基于配置文件的權(quán)限控制這個功能的重用并不適合ASP.NET MVC的開發(fā)。綜合對比一下,至少在ASP.NET MVC開發(fā)中,Membership所帶來的重用微乎其微。
在不同的權(quán)限管理系統(tǒng)中,對控制級別的要求是不一樣的,如:頁面訪問級別、數(shù)據(jù)訪問級別、控件訪問級別、函數(shù)級別??墒遣徽撌且刂频侥莻€級別,權(quán)限管理系統(tǒng)所要完成的功能都是一樣的 。我們不妨給權(quán)限管理系統(tǒng)下一個定義:權(quán)限管理系統(tǒng)就是告訴其它模塊用戶/角色對特定的資源/功能是否具有訪問的權(quán)限。
在Webform中,用戶跟角色相比,角色是不穩(wěn)定因素,用戶是相對較穩(wěn)定的因素。因此權(quán)限系統(tǒng)的輸入?yún)?shù)中我們通常會傳入用戶,而不輸入角色,因為角色是不穩(wěn)定的,至于說用戶屬于哪個角色,權(quán)限系統(tǒng)是可以查出來的。
而在ASP.NET MVC中,用戶跟角色都可以是較穩(wěn)定因素,因為用戶的權(quán)限控制跟角色的權(quán)限控制都是通過擴(kuò)展標(biāo)記屬性來實現(xiàn)的。這是跟webform相比,權(quán)限系統(tǒng)設(shè)計上不一樣的地方。
ASP.NET MVC中權(quán)限控制是通過對Action的攔截實現(xiàn)的。實現(xiàn)的方式如下:
定義一個擴(kuò)展屬性標(biāo)記類,繼承自接口IActionFilter的抽象類ActionFilterAttribute。重寫ActionFilterAttribute中的虛方法。將擴(kuò)展標(biāo)記作用于Controller跟Action。關(guān)于ASP.NET MVC中的權(quán)限管理方案,網(wǎng)上已經(jīng)有了,這里就不過多的贅述了。
以下是我前段時間設(shè)計的權(quán)限管理系統(tǒng)的類關(guān)系圖,只完成了部分的設(shè)計,還有個別部分沒有加上, 是使用PowerDesigner 15設(shè)計的,由于這段時間非常的忙,沒有繼續(xù)完成剩下的功能。如果以后有時間,我會完成剩下的設(shè)計,然后重新上傳。
權(quán)限管理系統(tǒng)類關(guān)系圖下載地址:http://files.cnblogs.com/wlb/%E6%9D%83%E9%99%90%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1.rar
標(biāo)題名稱:淺談ASP.NETMVCMembership權(quán)限機(jī)制
本文來源:http://www.dlmjj.cn/article/dpdppgg.html


咨詢
建站咨詢
