AngularJS's ng Http Request and response format conversion method
- 高洛峰Original
- 2016-12-07 14:47:501754browse
Identity authentication can often be applied in the web. This article introduces the skills of using identity authentication in AngularJS. Without further ado, let’s read on.
Identity Authentication
The most common identity authentication method is to use username (or email) and password to log in. This means implementing a login form so that users can log in with their personal information. The form looks like this:
<form name="loginForm" ng-controller="LoginController"
ng-submit="login(credentials)" novalidate>
<label for="username">Username:</label>
<input type="text" id="username"
ng-model="credentials.username">
<label for="password">Password:</label>
<input type="password" id="password"
ng-model="credentials.password">
<button type="submit">Login</button>
</form>
Since this is an Angular-powered form, we use the ngSubmit directive to trigger the function when uploading the form. One thing to note is that we pass the personal information into the upload form function instead of using the $scope.credentials object directly. This makes the function easier to unit-test and reduces the coupling of the function to the current Controller scope. This Controller looks like this:
.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);
})
We noticed that there is a lack of actual logic here. This Controller is made like this to decouple the authentication logic from the form. It is a good idea to extract as much logic as possible from our Controller and put it all into services. AngularJS's Controller should only manage the objects in $scope (using watching or manual operation) instead of taking on too many overly heavy tasks.
Notify Session changes
Identity authentication will affect the state of the entire application. For this reason I prefer to use events (using $broadcast) to notify user session changes. It is a good idea to define all the event codes that may be used in a middle ground. I like to use constants to do this:
.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'
})
One good feature of constants is that they can be injected into other places at will, just like services. This makes constants easily callable by our unit-test. Constants also allow you to easily rename them later without having to change a bunch of files. The same trick works with user roles:
.constant('USER_ROLES', {
all: '*',
admin: 'admin',
editor: 'editor',
guest: 'guest'
})
If you want to give editors and administrators the same permissions, you simply change ‘editor’ to ‘admin’.
The AuthService
Logic related to authentication and authorization (access control) is best placed in the same service:
.factory('AuthService', function ($http, Session) {
var authService = {};
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);
return res.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);
};
return authService;
})
To further distance myself from authentication concerns, I use another service (a Singleton object, using the service style) to save the user's session information. The details of session information depend on the backend implementation, but I will give a more general example:
.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;
};
return this;
})
Once the user logs in, his information should be displayed in certain places (such as the upper right corner) User avatar or something). In order to achieve this, the user object must be referenced by the $scope object, preferably one that can be called globally. Although $rootScope is the obvious first choice, I try to restrain myself from using $rootScope too much (I actually only use $rootScope for global event broadcasts). The way I prefer to do this is to define a controller at the root node of the application, or somewhere else at least higher than the DOM tree. Tags are a good choice:
<body ng-controller="ApplicationController"> ... </body>
ApplicationController is a container for the global logic of the application and an option for running Angular's run method. Therefore it will be at the root of the $scope tree, and all other scopes will inherit from it (except the isolation scope). This is a good place to define the currentUser object:
.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;
};
})
We don’t actually allocate the currentUser object, we just initialize the scoped properties so that currentUser can be accessed later. Unfortunately, we can't simply assign a new value to currentUser in the child scope because that would create a shadow property. This is the result of passing primitive types (strings, numbers, booleans, undefined and null) by value instead of by reference. To prevent shadow properties, we have to use setter functions. If you want to learn more about Angular scopes and prototypal inheritance, read Understanding Scopes.
Access control
Identity authentication, that is, access control, actually does not exist in AngularJS. Because we are a client application, all source code is in the hands of the user. There is no way to prevent users from tampering with the code to obtain an authenticated interface. All we can do is show the controls. If you need true authentication, you'll need to do it server-side, but that's beyond the scope of this article.
Limit the display of elements
AngularJS has directives to control showing or hiding elements based on scope or expression: ngShow, ngHide, ngIf and ngSwitch. The first two will hide the element using a c9ccee2e6ea535a969eb3f532ad9fe89 attribute, but the last two will remove the element from the DOM.
第一种方式，也就是隐藏元素，最好用于表达式频繁改变并且没有包含过多的模板逻辑和作用域引用的元素上。原因是在隐藏的元素里，这些元素的模板逻辑仍然会在每个 digest 循环里重新计算，使得应用性能下降。第二种方式，移除元素，也会移除所有在这个元素上的 handler 和作用域绑定。改变 DOM 对于浏览器来说是很大工作量的（在某些场景，和 ngShow/ngHide 对比），但是在很多时候这种代价是值得的。因为用户访问信息不会经常改变，使用 ngIf 或 ngShow 是最好的选择：
<div ng-if="currentUser">Welcome, {{ currentUser.name }}</div>
<div ng-if="isAuthorized(userRoles.admin)">You're admin.</div>
<div ng-switch on="currentUser.role">
<div ng-switch-when="userRoles.admin">You're admin.</div>
<div ng-switch-when="userRoles.editor">You're editor.</div>
<div ng-switch-default>You're something else.</div>
</div>
限制路由访问
很多时候你会想让整个网页都不能被访问，而不是仅仅隐藏一个元素。如果可以再路由（在UI Router 里，路由也叫状态）使用一种自定义的数据结构，我们就可以明确哪些用户角色可以被允许访问哪些内容。下面这个例子使用 UI Router 的风格，但是这些同样适用于 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（UI Router 里的）事件：
.run(function ($rootScope, AUTH_EVENTS, AuthService) {
$rootScope.$on('$stateChangeStart', function (event, next) {
var authorizedRoles = next.data.authorizedRoles;
if (!AuthService.isAuthorized(authorizedRoles)) {
event.preventDefault();
if (AuthService.isAuthenticated()) {
// user is not allowed
$rootScope.$broadcast(AUTH_EVENTS.notAuthorized);
} else {
// user is not logged in
$rootScope.$broadcast(AUTH_EVENTS.notAuthenticated);
}
}
});
})
Session 时效
身份认证多半是服务器端的事情。无论你用什么实现方式，你的后端会对用户信息做真正的验证和处理诸如 Session 时效和访问控制的处理。这意味着你的 API 会有时返回一些认证错误。标准的错误码就是 HTTP 状态吗。普遍使用这些错误码：
401 Unauthorized — The user is not logged in
403 Forbidden — The user is logged in but isn't allowed access
419 Authentication Timeout (non standard) — Session has expired
440 Login Timeout (Microsoft only) — Session has expired
后两种不是标准内容，但是可能广泛应用。最好的官方的判断 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: '<div ng-if="visible"
ng-include="\'login-form.html\'">',
link: function (scope) {
var showDialog = function () {
scope.visible = true;
};
scope.visible = false;
scope.$on(AUTH_EVENTS.notAuthenticated, showDialog);
scope.$on(AUTH_EVENTS.sessionTimeout, showDialog)
}
};
})
只要你喜欢，这个对话框可以随便扩展。主要的思想是重用已存在的登陆表单模板和 LoginController。你需要在每个页面写上如下的代码：
<div login-dialog ng-if="!isLoginPage"></div>
注意 isLoginPage 检查。一个失败了的登陆会触发 notAuthenticated 时间，但我们不想在登陆页面显示这个对话框，因为这很多余和奇怪。这就是为什么我们不把登陆对话框也放在登陆页面的原因。所以在 ApplicationController 里定义一个 $scope.isLoginPage 是合理的。
保存用户状态
在用户刷新他们的页面，依旧保存已登陆的用户信息是单页应用认证里面狡猾的一个环节。因为所有状态都存在客户端，刷新会清空用户信息。为了修复这个问题，我通常实现一个会返回已登陆的当前用户的数据的 API （比如 /profile），这个 API 会在 AngularJS 应用启动（比如在 “run” 函数）。然后用户数据会被保存在 Session 服务或者 $rootScope，就像用户已经登陆后的状态。或者，你可以把用户数据直接嵌入到 index.html，这样就不用额外的请求了。第三种方式就是把用户数据存在 cookie 或者 LocalStorage，但这会使得登出或者清空用户数据变得困难一点。