Angularjs中的頁面存取權限怎麼設定_AngularJS

　　在以往的項目中，前後端常見的配合方式是前端提供頁面和ui加一點DuangDuangDuang的效果，後端搭建架構資料結構和資料互動(資料互動前後端有交集)，不管是.net、java or php都能一對多的提供前端服務，然而在新形式下項目中運用了前端架構，開發情況就不一樣了，比如我要說的這是在angular架構下完成的開發，模式是後端提供服務和api文檔，頁面和資料互動及邏輯處理由前端完成，前端儼然是個完全的programer了，這個過程中就會遇到之前意想不到的問題(如果沒有做過後端開發)，比如頁面許可權控制，不得不說，使用前端的方式去做這些設定比較糾結，因為這方面的資料，也就是這些許可權的‘標示'，後端啟動並執行時候是可以直接獲得的，即像擷取欄位資料a.b點一下就出來了，而前端只能用http請求的方式擷取，繁瑣麻煩；

　　其實在ng中做頁面訪問權有很多種方法，各有利弊，運用的比較多的是攔截器，攔截器使得在前端往後端發送http請求之前或之後做一些操作，比如全域監測使用者是否登入，沒登陸就要跳轉的登入頁面，登入就可以訪問頁面；攔截器的使用往往配合後台資料，也就是擷取到最新的‘標示'，來確定這個頁面或者下個頁面要做什麼操作；而這裡我使用的是一種用前端控制的方式，不用資料互動，理念就是定義好不同等級/階段可以訪問的頁面，在路由的地方作攔截，針對一些不同等級/階段存取權限定義明確的可以參考使用這種方法，代碼如下：

......app.run(['$rootScope', '$state', '$window', function($rootScope, $state, $window) {$rootScope.$on('$stateChangeStart', function(event, toState, toStateParams) {//使用者訪問等級階段， 0 1 2Array.prototype.contains = function(needle) {for(i in this) {if(this[i] == needle) return true;}return false;}var status=new Array("user.a","user.b","user.c","user.d","user.e","user.f","user.g");var status0=new Array("user.a","user.b");var status1=new Array("user.c","user.d");var status2=new Array("user.a","user.b","user.c","user.d"); 　　　　　if (status.contains(toState.name)) {　　　　　　　if(initObj.getStatus()=="0"){if(!status0.contains(toState.name)){event.preventDefault();$state.go('user.approve');}return;}if(initObj.getStatus()=="1"){if(!status1.contains(toState.name)){event.preventDefault();$state.go('user.result');}return;}if(initObj.getStatus()=="2"){if(!status2.contains(toState.name)){event.preventDefault();$state.go('user.result');}return;}}})}])......

　　如碼所示，在ng的run裡加上state監聽(我這裡使用了an-route-ui)，當監聽到路由跳轉的時候就進行檢測，這裡設想的可訪問‘標示'的status數組裡包含每個層級/階段可訪問的頁面/路由，比如status裡是需要檢測的全集，status0、1 2分別是不同的層級/階段的許可權訪問集合，也即是ng中路由跳轉的雜湊值，也就代表了可訪問的頁面，利用這種檢測手段，沒有存取權限的使用者就不能訪問某些頁面，比如使用者a的的層級階段配置是status1,包含user.c和user.d，initObj.getStatus()返回了他的狀態代碼是1，當他想訪問user.a頁面的時候，就會進入initObj.getStatus()=="1"的判斷，但是他的配置可訪問頁面不包括user.a，也即!status1.contains(toState.name)（toState.name返回要跳轉的頁面，這裡返回user.a），接下來進入下面的操作，進入公用頁面或提示頁面，原理基本是這樣；

　　當然，這種方式跟後端的控制來說，是非常不安全的，也不嚴謹，因為就算項目中指令碼進行發布壓縮混淆後，細細瀏覽還是能找到這裡的設定痕迹的，並且指令碼在運行之前是可編輯的，這就會造成很大的漏洞；不過在一些小項目中使用這些配置夠用了，並且就算有人修改了這個status配置，資料什麼的都是從後端請求的，狀態不對也請求不到資料的，所以攻陷資料庫才算是真黑，從前端的指令碼做攔截只是玩玩測試；

　　繼續發掘其他的最佳化方法，有大神有更好的方法可以交流下；先到這裡吧。

　　還有，光棍節到了，祝廣大單身狗早日脫單。嘿嘿~~~~