登錄用戶： 1.用戶名：牛頭人戰(zhàn)士 密碼:000000 權(quán)限：有全部菜單頁面，不能進行數(shù)據(jù)庫的更改操作（不影響錄入體驗）
 
　　　　　 2.用戶名：老虎MM  密碼:000000  權(quán)限：少兩個菜單頁面，不能進行數(shù)據(jù)庫的更改操作（不影響錄入體驗）
 
　　　　　 3.用戶名：admin 密碼不公開 權(quán)限：所有權(quán)限
 
　　　　　 注：以上的實現(xiàn)都是通過權(quán)限管理s配置出的哈，沒有任何硬編碼
 
權(quán)限判斷的邊界
 
由于項目是基于MVC的，除去數(shù)據(jù)權(quán)限不說，功能權(quán)限的判斷邊界做在MVC 的Action上無疑是最好的選擇，因為無論是一個頁面，還是一個按鈕，還是一次查詢，都是通過Action請求實現(xiàn)的。這樣我們只需要在每個Action請求執(zhí)行之前進行權(quán)限判斷就可以了，也不用折騰RBAC里的資源 操作=權(quán)限 這么麻煩。
 
 
 
菜單權(quán)限和功能權(quán)限
 
其實在MIS項目中，大多數(shù)的權(quán)限判斷粒度還是頁面級的，再加上我們還需要根據(jù)權(quán)限動態(tài)生成用戶的菜單，所以我們把權(quán)限分成“菜單權(quán)限”和“功能權(quán)限”
 
菜單權(quán)限：在用戶登錄驗證后，每個頁面的請求都必須通過權(quán)限驗證。
 
功能權(quán)限：默認(rèn)客戶進入頁面后，頁面的相關(guān)操作默認(rèn)都不判斷，只對顯示維護出的功能權(quán)限進行權(quán)限判斷。
 
這樣有幾個好處：一般情況下權(quán)限的配置簡單了，因為只需要配置粗粒度的頁面權(quán)限即可使用；增加了效率，不必每個Action執(zhí)行之前都判斷權(quán)限（雖然都做了緩存，但能少判斷一次還是好的）；完全不影響細(xì)粒度的權(quán)限判斷，隨時都可以增加對任何一個Action的權(quán)限判定