AngularJS 应用身份认证的技巧总结
在web中很多时候都能应用到身份认证，本文介绍了AngularJS应用身份认证的技巧，废话不多说了一起往下看吧。
身份认证
最普遍的身份认证方式就是用用户名（或email）和密码做登陆操作。这就意味要实现一个登陆的表单，以便用户能够用他们个人信息登陆。这个表单看起来是这样的：
<formname="loginForm"ng-controller="LoginController" ng-submit="login(credentials)"novalidate> <labelfor="username">Username:</label> <inputtype="text"id="username" ng-model="credentials.username"> <labelfor="password">Password:</label> <inputtype="password"id="password" ng-model="credentials.password"> <buttontype="submit">Login</button> </form>
既然这个是Angular-powered的表单，我们使用ngSubmit指令去触发上传表单时的函数。注意一点的是，我们把个人信息传入到上传表单的函数，而不是直接使用$scope.credentials这个对象。这样使得函数更容易进行unit-test和降低这个函数与当前Controller作用域的耦合。这个Controller看起来是这样的：
.controller('LoginController',function($scope,$rootScope,AUTH_EVENTS,AuthService){
$scope.credentials={
username:'',
password:''
};
$scope.login=function(credentials){
AuthService.login(credentials).then(function(user){
$rootScope.$broadcast(AUTH_EVENTS.loginSuccess);
$scope.setCurrentUser(user);
},function(){
$rootScope.$broadcast(AUTH_EVENTS.loginFailed);
});
};javascript:void(0);
})
我们注意到这里是缺少实际的逻辑的。这个Controller被做成这样，目的是使身份认证的逻辑跟表单解耦。把逻辑尽可能的从我们的Controller里面抽离出来，把他们都放到services里面，这是个很好的想法。AngularJS的Controller应该只管理$scope里面的对象（用watching或者手动操作）而不是承担过多过分重的东西。
通知Session的变化
身份认证会影响整个应用的状态。基于这个原因我更推荐使用事件（用$broadcast）去通知usersession的改变。把所有可能用到的事件代码定义在一个中间地带是个不错的选择。我喜欢用constants去做这个事情：
.constant('AUTH_EVENTS',{
loginSuccess:'auth-login-success',
loginFailed:'auth-login-failed',
logoutSuccess:'auth-logout-success',
sessionTimeout:'auth-session-timeout',
notAuthenticated:'auth-not-authenticated',
notAuthorized:'auth-not-authorized'
})
constants有个很好的特性就是他们能随便注入到别的地方，就像services那样。这样使得constants很容易被我们的unit-test调用。constants也允许你很容易地在随后对他们重命名而不需要改一大串文件。同样的戏法运用到了userroles:
.constant('USER_ROLES',{
all:'*',
admin:'admin',
editor:'editor',
guest:'guest'
})
如果你想给予editors和administrators同样的权限，你只需要简单地把‘editor'改成‘admin'。
TheAuthService
与身份认证和授权（访问控制）相关的逻辑最好被放到同一个service：
.factory('AuthService',function($http,Session){
varauthService={};
authService.login=function(credentials){
return$http
.post('/login',credentials)
.then(function(res){
Session.create(res.data.id,res.data.user.id,
res.data.user.role);
returnres.data.user;
});
};
authService.isAuthenticated=function(){
return!!Session.userId;
};
authService.isAuthorized=function(authorizedRoles){
if(!angular.isArray(authorizedRoles)){
authorizedRoles=[authorizedRoles];
}
return(authService.isAuthenticated()&&
authorizedRoles.indexOf(Session.userRole)!==-1);
};
returnauthService;
})
为了进一步远离身份认证的担忧，我使用另一个service（一个单例对象，usingtheservicestyle）去保存用户的session信息。session的信息细节是依赖于后端的实现，但是我还是给出一个较普遍的例子吧：
.service('Session',function(){
this.create=function(sessionId,userId,userRole){
this.id=sessionId;
this.userId=userId;
this.userRole=userRole;
};
this.destroy=function(){
this.id=null;
this.userId=null;
this.userRole=null;
};
returnthis;
})
一旦用户登录了，他的信息应该会被展示在某些地方（比如右上角用户头像什么的）。为了实现这个，用户对象必须要被$scope对象引用，更好的是一个可以被全局调用的地方。虽然$rootScope是显然易见的第一个选择，但是我尝试克制自己，不过多地使用$rootScope（实际上我只在全局事件广播使用$rootScope）。用我所喜欢的方式去做这个事情，就是在应用的根节点，或者在别的至少高于Dom树的地方，定义一个controller。标签是个很好的选择：
<bodyng-controller="ApplicationController"> ... </body>
ApplicationController是应用的全局逻辑的容器和一个用于运行Angular的run方法的选择。因此它要处于$scope树的根，所有其他的scope会继承它（除了隔离scope）。这是个很好的地方去定义currentUser对象：
.controller('ApplicationController',function($scope,
USER_ROLES,
AuthService){
$scope.currentUser=null;
$scope.userRoles=USER_ROLES;
$scope.isAuthorized=AuthService.isAuthorized;
$scope.setCurrentUser=function(user){
$scope.currentUser=user;
};
})
我们实际上不分配currentUser对象，我们仅仅初始化作用域上的属性以便currentUser能在后面被访问到。不幸的是，我们不能简单地在子作用域分配一个新的值给currentUser因为那样会造成shadowproperty。这是用以值传递原始类型（strings，numbers，booleans，undefinedandnull）代替以引用传递原始类型的结果。为了防止shadowproperty，我们要使用setter函数。如果想了解更多Angular作用域和原形继承，请阅读UnderstandingScopes。
访问控制
身份认证，也就是访问控制，其实在AngularJS并不存在。因为我们是客户端应用，所有源码都在用户手上。没有办法阻止用户篡改代码以获得认证后的界面。我们能做的只是显示控制。如果你需要真正的身份认证，你需要在服务器端做这个事情，但是这个超出了本文范畴。
限制元素的显示
AngularJS拥有基于作用域或者表达式来控制显示或者隐藏元素的指令：ngShow，ngHide，ngIf和ngSwitch。前两个会使用一个<style>属性去隐藏元素，但是后两个会从DOM移除元素。
第一种方式，也就是隐藏元素，最好用于表达式频繁改变并且没有包含过多的模板逻辑和作用域引用的元素上。原因是在隐藏的元素里，这些元素的模板逻辑仍然会在每个digest循环里重新计算，使得应用性能下降。第二种方式，移除元素，也会移除所有在这个元素上的handler和作用域绑定。改变DOM对于浏览器来说是很大工作量的（在某些场景，和ngShow/ngHide对比），但是在很多时候这种代价是值得的。因为用户访问信息不会经常改变，使用ngIf或ngShow是最好的选择：
<divng-if="currentUser">Welcome,{{currentUser.name}}</div>
<divng-if="isAuthorized(userRoles.admin)">You'readmin.</div>
<divng-switchon="currentUser.role">
<divng-switch-when="userRoles.admin">You'readmin.</div>
<divng-switch-when="userRoles.editor">You'reeditor.</div>
<divng-switch-default>You'resomethingelse.</div>
</div>
限制路由访问
很多时候你会想让整个网页都不能被访问，而不是仅仅隐藏一个元素。如果可以再路由（在UIRouter里，路由也叫状态）使用一种自定义的数据结构，我们就可以明确哪些用户角色可以被允许访问哪些内容。下面这个例子使用UIRouter的风格，但是这些同样适用于ngRoute。
.config(function($stateProvider,USER_ROLES){
$stateProvider.state('dashboard',{
url:'/dashboard',
templateUrl:'dashboard/index.html',
data:{
authorizedRoles:[USER_ROLES.admin,USER_ROLES.editor]
}
});
})
下一步，我们需要检查每次路由变化（就是用户跳转到其他页面的时候）。这需要监听$routeChangStart（ngRoute里的）或者$stateChangeStart（UIRouter里的）事件：
.run(function($rootScope,AUTH_EVENTS,AuthService){
$rootScope.$on('$stateChangeStart',function(event,next){
varauthorizedRoles=next.data.authorizedRoles;
if(!AuthService.isAuthorized(authorizedRoles)){
event.preventDefault();
if(AuthService.isAuthenticated()){
//userisnotallowed
$rootScope.$broadcast(AUTH_EVENTS.notAuthorized);
}else{
//userisnotloggedin
$rootScope.$broadcast(AUTH_EVENTS.notAuthenticated);
}
}
});
})
Session时效
身份认证多半是服务器端的事情。无论你用什么实现方式，你的后端会对用户信息做真正的验证和处理诸如Session时效和访问控制的处理。这意味着你的API会有时返回一些认证错误。标准的错误码就是HTTP状态吗。普遍使用这些错误码：
- 401Unauthorized — Theuserisnotloggedin
- 403Forbidden — Theuserisloggedinbutisn'tallowedaccess
- 419AuthenticationTimeout(nonstandard) — Sessionhasexpired
- 440LoginTimeout(Microsoftonly) — Sessionhasexpired
后两种不是标准内容，但是可能广泛应用。最好的官方的判断session过期的错误码是401。无论怎样，你的登陆对话框都应该在API返回401，419，440或者403的时候马上显示出来。总的来说，我们想广播和基于这些HTTP返回码的时间，为此我们在$httpProvider增加一个拦截器：
.config(function($httpProvider){
$httpProvider.interceptors.push([
'$injector',
function($injector){
return$injector.get('AuthInterceptor');
}
]);
})
.factory('AuthInterceptor',function($rootScope,$q,
AUTH_EVENTS){
return{
responseError:function(response){
$rootScope.$broadcast({
401:AUTH_EVENTS.notAuthenticated,
403:AUTH_EVENTS.notAuthorized,
419:AUTH_EVENTS.sessionTimeout,
440:AUTH_EVENTS.sessionTimeout
}[response.status],response);
return$q.reject(response);
}
};
})
这只是一个认证拦截器的简单实现。有个很棒的项目在Github，它做了相同的事情，并且使用了httpBuffer服务。当返回HTTP错误码时，它会阻止用户进一步的请求，直到用户再次登录，然后继续这个请求。
登录对话框指令
当一个session过期了，我们需要用户重新进入他的账号。为了防止他丢失他当前的工作，最好的方法就是弹出登录登录对话框，而不是跳转到登录页面。这个对话框需要监听notAuthenticated和sessionTimeout事件，所以当其中一个事件被触发了，对话框就要打开：
.directive('loginDialog',function(AUTH_EVENTS){
return{
restrict:'A',
template:'<divng-if="visible"
ng-include="\'login-form.html\'">',
link:function(scope){
varshowDialog=function(){
scope.visible=true;
};
scope.visible=false;
scope.$on(AUTH_EVENTS.notAuthenticated,showDialog);
scope.$on(AUTH_EVENTS.sessionTimeout,showDialog)
}
};
})
只要你喜欢，这个对话框可以随便扩展。主要的思想是重用已存在的登陆表单模板和LoginController。你需要在每个页面写上如下的代码：
<divlogin-dialogng-if="!isLoginPage"></div>
注意isLoginPage检查。一个失败了的登陆会触发notAuthenticated时间，但我们不想在登陆页面显示这个对话框，因为这很多余和奇怪。这就是为什么我们不把登陆对话框也放在登陆页面的原因。所以在ApplicationController里定义一个$scope.isLoginPage是合理的。
保存用户状态
在用户刷新他们的页面，依旧保存已登陆的用户信息是单页应用认证里面狡猾的一个环节。因为所有状态都存在客户端，刷新会清空用户信息。为了修复这个问题，我通常实现一个会返回已登陆的当前用户的数据的API（比如/profile），这个API会在AngularJS应用启动（比如在“run”函数）。然后用户数据会被保存在Session服务或者$rootScope，就像用户已经登陆后的状态。或者，你可以把用户数据直接嵌入到index.html，这样就不用额外的请求了。第三种方式就是把用户数据存在cookie或者LocalStorage，但这会使得登出或者清空用户数据变得困难一点。
最后……
鄙人才疏学浅，一点点经验，这是一篇翻译的文章，如有谬误，欢迎指正。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持毛票票。