Angularjs中的页面访问权限怎么设置
在以往的项目中，前后端常见的配合方式是前端提供页面和ui加一点DuangDuangDuang的效果，后端搭建框架数据结构和数据交互(数据交互前后端有交集)，不管是.net、javaorphp都能一对多的提供前端服务，然而在新形式下项目中运用了前端框架，开发情况就不一样了，比如我要说的这是在angular框架下完成的开发，模式是后端提供服务和api文档，页面和数据交互及逻辑处理由前端完成，前端俨然是个完全的programer了，这个过程中就会遇到之前意想不到的问题(如果没有做过后端开发)，比如页面权限控制，不得不说，使用前端的方式去做这些设置比较纠结，因为这方面的数据，也就是这些权限的‘标示'，后端运行的时候是可以直接获得的，即像获取字段数据a.b点一下就出来了，而前端只能用http请求的方式获取，繁琐麻烦；
其实在ng中做页面访问权有很多种方法，各有利弊，运用的比较多的是拦截器，拦截器使得在前端往后端发送http请求之前或之后做一些操作，比如全局监测用户是否登录，没登陆就要跳转的登录页面，登录就可以访问页面；拦截器的使用往往配合后台数据，也就是获取到最新的‘标示'，来确定这个页面或者下个页面要做什么操作；而这里我使用的是一种用前端控制的方式，不用数据交互，理念就是定义好不同等级/阶段可以访问的页面，在路由的地方作拦截，针对一些不同等级/阶段访问权限定义明确的可以参考使用这种方法，代码如下：
......
app.run(['$rootScope','$state','$window',function($rootScope,$state,$window){
$rootScope.$on('$stateChangeStart',function(event,toState,toStateParams){
//用户访问等级阶段，012
Array.prototype.contains=function(needle){
for(iinthis){
if(this[i]==needle)returntrue;
}
returnfalse;
}
varstatus=newArray("user.a","user.b","user.c","user.d","user.e","user.f","user.g");
varstatus0=newArray("user.a","user.b");
varstatus1=newArray("user.c","user.d");
varstatus2=newArray("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、12分别是不同的层级/阶段的权限访问集合，也即是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配置，数据什么的都是从后端请求的，状态不对也请求不到数据的，所以攻陷数据库才算是真黑，从前端的脚本做拦截只是玩玩测试；
继续发掘其他的优化方法，有大神有更好的方法可以交流下；先到这里吧。
还有，光棍节到了，祝广大单身狗早日脱单。嘿嘿~~~~