在以往的项目中,前后端常见的配合方式是前端提供页面和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 2
Array.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配置,数据什么的都是从后端请求的,状态不对也请求不到数据的,所以攻陷数据库才算是真黑,从前端的脚本做拦截只是玩玩测试;
继续发掘其他的优化方法,有大神有更好的方法可以交流下;先到这里吧。
本文原创发布php中文网,转载请注明出处,感谢您的尊重!