許可權管理是個老生常談的功能,我看部落格園也有不少“高手”寫了相關的文章,但大多不是空談理論,就是做的十分傻瓜和玩具差不多沒有真正項目實用性。少數基於RBAC的看設計還可以,但猶抱琵琶半遮面的,談到關鍵實現就陽痿,生怕別人學到似的。
許可權管理是每個項目都要用到的,但一般想寫好也有一定難度。所以不少人動不動就想做所謂“通用許可權管理”,但基本我看都是雷聲大雨點小。弦哥也寫過所謂通用許可權 ,什麼基於RBAC,什麼資源+操作=許可權。搞來搞去靈活是靈活了,結果配置十分複雜在項目中使用並不理想,再加上“通用”二字,那就必須要獨立於平台技術和項目,實現解耦,而許可權是經常都需要訪問的,所以資料轉送,效率也成了大問題。
而且通用許可權的需求是非常多的,一般很難想全,我看園子裡吉日哥雖然技術不咋地,但徵集許可權需求這個路子還是對的,至少比有些人隨便寫個玩具就敢號稱“通用許可權”來的好些。
BB了這麼多,來說說我的許可權管理吧,正如上面所說我基本放棄搞所謂通用許可權了,在吉日哥非常牛X非常通用的許可權管理露出真面目之前,我覺得針對不同項目特點寫不同的許可權管理功能還是目前比較可行辦法。所以我的這個許可權通用肯定不敢說,只能說是局限在MVC架構下的,滿足我這個項目需求的許可權管理。
由于吉日哥的許可權老是遮遮掩掩,我看他放出的那點代碼也非常蹩腳,他的通用許可權不知道啥時候才能完全憋出來...所以弦哥帶上全部Demo和源碼給大家一個安慰吧。
由於篇幅有限 資料庫訪問這塊我不解釋(之前的系列已經很詳細的講過了),EXTJS代碼我不解釋(之後會詳細寫EXTJS的典型應用情境),凡涉及到與許可權無關的代碼我不解釋(大家有興趣可以提出來,以後我詳細介紹)。
上傳完demo都淩晨6點了,太累。。。下篇再放詳細的實現思路和代碼吧,全部可啟動並執行源碼也在下篇放出來....有大家有啥意見可以提出來,在下篇解釋。
雖然有了demo但發圖的國際慣例不能丟:
線上Demo:
地址:http://218.60.8.35:1234/
伺服器:網通
連接埠:不要禁用1234連接埠應該就可以訪問
注意:連了資料庫的,時間倉促肯定有漏洞,不要搗亂哈:)
登入使用者: 1.使用者名稱:牛頭人戰士 密碼:000000 許可權:有全部菜單頁面,不能進行資料庫的更改操作(不影響錄入體驗)
2.使用者名稱:老虎MM 密碼:000000 許可權:少兩個菜單頁面,不能進行資料庫的更改操作(不影響錄入體驗)
3.使用者名稱:admin 密碼不公開 許可權:所有許可權
註:以上的實現都是通過許可權管理s配置出的哈,沒有任何寫入程式碼
適用項目:
基於Asp.Net MVC開發並嚴格按照MVC思想進行編碼的MIS項目
功能模組:
使用者管理
科室管理
角色管理
菜單管理
Atcion粒度的功能許可權管理
登入,登出等
關鍵概述:
使用者和科室是多對多的..
使用者和角色是多對多的..
角色和菜單是多對多的..
角色和Atcion是多對多的..
角色是可以繼承的..
登入是用內建的Form驗證的..
所有許可權判定相關的資料都是緩衝的..
菜單是動態配置的..
Action許可權維護是通過反射出來的,方便選取(許可權判斷等沒有用反射)...
最小許可權判定的邊界是在Action請求...
判斷邏輯是菜單許可權必須判斷,Action細粒度的功能許可權只有被維護才判斷...
由於是Asp.net MVC +Ext 所以基本頁面上的每個操作(Action請求)都可以控制到的。肯定是可以滿足MIS類項目的許可權控制粒度需求了...
是通過自訂的MVC的Filter實現的(沒有用內建的那個AuthorizeAttribute)...
局限性:
只能基於ASP.NET MVC下使用...
沒有資料許可權管理(自己可以加...我看用AOP方式實現就不錯)...
如多級授權,單點登入等擴充功能沒有實現(自己可以擴充)...
表設計: