"/> ">
Heim >Web-Frontend >js-Tutorial >Detaillierte Codebeispiele zur Verwendung von AngularJS zur Authentifizierung
Identitätsauthentifizierung
Die gebräuchlichste Methode zur Identitätsauthentifizierung ist die Verwendung eines Benutzernamens (oder einer E-Mail-Adresse) und eines Passworts zur Anmeldung. Dies bedeutet die Implementierung eines Anmeldeformulars, damit sich Benutzer mit ihren persönlichen Daten anmelden können. Das Formular sieht so aus:
<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>
Da es sich um ein Angular-basiertes Formular handelt, verwenden wir die ngSubmit-Direktive, um die Funktion beim Hochladen des Formulars auszulösen. Beachten Sie, dass wir die persönlichen Informationen an die Funktion zum Hochladen des Formulars übergeben, anstatt das Objekt $scope.credentials direkt zu verwenden. Dies erleichtert den Unit-Test der Funktion und verringert die Kopplung der Funktion an den aktuellen Controller-Bereich. Der Controller sieht so aus:
.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); })
Wir bemerken, dass es hier an tatsächlicher Logik mangelt. Dieser Controller ist so aufgebaut, dass er die Authentifizierungslogik vom Formular entkoppelt. Es ist eine gute Idee, so viel Logik wie möglich aus unserem Controller zu extrahieren und alles in Dienste zu packen. Der Controller von AngularJS sollte nur die Objekte im $scope verwalten (durch Überwachung oder manuelle Bedienung), anstatt zu viele übermäßig schwere Aufgaben zu übernehmen.
Benachrichtigung über Sitzungsänderungen
Die Identitätsauthentifizierung wirkt sich auf den Status der gesamten Anwendung aus. Aus diesem Grund verwende ich lieber Ereignisse (mit $broadcast), um Benutzersitzungsänderungen zu benachrichtigen. Es ist eine gute Idee, alle Ereigniscodes zu definieren, die in einem Mittelweg verwendet werden können. Dazu verwende ich gerne Konstanten:
.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' })
Eine gute Eigenschaft von Konstanten ist, dass sie wie Dienste nach Belieben an anderen Stellen eingefügt werden können. Dadurch können Konstanten von unserem Unit-Test leicht aufgerufen werden. Mit Konstanten können Sie sie später auch einfach umbenennen, ohne eine Reihe von Dateien ändern zu müssen. Der gleiche Trick funktioniert mit Benutzerrollen:
.constant('USER_ROLES', { all: '*', admin: 'admin', editor: 'editor', guest: 'guest' })
Wenn Sie Redakteuren und Administratoren die gleichen Berechtigungen geben möchten, ändern Sie einfach „Editor“ in „Administrator“.
Der AuthService
Logik im Zusammenhang mit der Identitätsauthentifizierung und -autorisierung (Zugriffskontrolle) lässt sich am besten im selben Dienst platzieren:
.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; })
Um mich weiter von den Bedenken der Identitätsauthentifizierung zu distanzieren, verwende ich einen anderen Dienst (ein Singleton-Objekt im Service-Stil), um die Sitzungsinformationen des Benutzers zu speichern. Die Details der Sitzungsinformationen hängen von der Backend-Implementierung ab, aber ich gebe ein allgemeineres Beispiel:
.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; })
Sobald sich der Benutzer anmeldet, sollten seine Informationen an einigen Stellen angezeigt werden (z. B. Benutzer-Avatar oder so). in der oberen rechten Ecke). Um dies zu erreichen, muss das Benutzerobjekt durch das $scope-Objekt referenziert werden, vorzugsweise eines, das global aufgerufen werden kann. Obwohl $rootScope die offensichtliche erste Wahl ist, versuche ich, $rootScope nicht zu häufig zu verwenden (eigentlich verwende ich $rootScope nur für globale Ereignisübertragungen). Am liebsten definiere ich dazu einen Controller am Stammknoten der Anwendung oder an einer anderen Stelle, die zumindest höher als der DOM-Baum liegt. Tags sind eine gute Wahl:
<body ng-controller="ApplicationController"> ... </body>
ApplicationController ist ein Container für die globale Logik der Anwendung und eine Option zum Ausführen der Ausführungsmethode von Angular. Daher befindet es sich im Stammverzeichnis des $scope-Baums und alle anderen Bereiche erben von ihm (mit Ausnahme des Isolationsbereichs). Dies ist ein guter Ort, um das currentUser-Objekt zu definieren:
.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; }; })
Wir weisen das currentUser-Objekt nicht wirklich zu, wir initialisieren lediglich die bereichsbezogenen Eigenschaften, damit auf currentUser später zugegriffen werden kann. Leider können wir „currentUser“ im untergeordneten Bereich nicht einfach einen neuen Wert zuweisen, da dadurch eine Schatteneigenschaft erstellt würde. Dies ist das Ergebnis der Übergabe primitiver Typen (Strings, Zahlen, Boolesche Werte, undefiniert und null) nach Wert statt nach Referenz. Um Schatteneigenschaften zu verhindern, müssen wir Setter-Funktionen verwenden. Wenn Sie mehr über Angular-Bereiche und prototypische Vererbung erfahren möchten, lesen Sie Understanding Scopes.
Zugriffskontrolle
Identitätsauthentifizierung, also Zugriffskontrolle, gibt es in AngularJS eigentlich nicht. Da wir eine Client-Anwendung sind, liegt der gesamte Quellcode in den Händen des Benutzers. Es gibt keine Möglichkeit, Benutzer daran zu hindern, den Code zu manipulieren, um eine authentifizierte Schnittstelle zu erhalten. Wir können nur die Steuerelemente anzeigen. Wenn Sie eine echte Authentifizierung benötigen, müssen Sie diese serverseitig durchführen, aber das würde den Rahmen dieses Artikels sprengen.
Anzeige von Elementen einschränken
AngularJS verfügt über Anweisungen zum Steuern des Ein- oder Ausblendens von Elementen basierend auf Umfang oder Ausdrücken: ngShow, ngHide, ngIf und ngSwitch. Die ersten beiden verbergen das Element mithilfe eines c9ccee2e6ea535a969eb3f532ad9fe89-Attributs, aber die letzten beiden entfernen das Element aus dem DOM.
第一种方式,也就是隐藏元素,最好用于表达式频繁改变并且没有包含过多的模板逻辑和作用域引用的元素上。原因是在隐藏的元素里,这些元素的模板逻辑仍然会在每个 digest 循环里重新计算,使得应用性能下降。第二种方式,移除元素,也会移除所有在这个元素上的 handler 和作用域绑定。改变 DOM 对于浏览器来说是很大工作量的(在某些场景,和 ngShow/ngHide 对比),但是在很多时候这种代价是值得的。因为用户访问信息不会经常改变,使用 ngIf 或 ngShow 是最好的选择:
<p ng-if="currentUser">Welcome, {{ currentUser.name }}</p> <p ng-if="isAuthorized(userRoles.admin)">You're admin.</p> <p ng-switch on="currentUser.role"> <p ng-switch-when="userRoles.admin">You're admin.</p> <p ng-switch-when="userRoles.editor">You're editor.</p> <p ng-switch-default>You're something else.</p> </p>
限制路由访问
很多时候你会想让整个网页都不能被访问,而不是仅仅隐藏一个元素。如果可以再路由(在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: '<p 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。你需要在每个页面写上如下的代码:
<p login-dialog ng-if="!isLoginPage"></p>
注意 isLoginPage 检查。一个失败了的登陆会触发 notAuthenticated 时间,但我们不想在登陆页面显示这个对话框,因为这很多余和奇怪。这就是为什么我们不把登陆对话框也放在登陆页面的原因。所以在 ApplicationController 里定义一个 $scope.isLoginPage 是合理的。
保存用户状态
在用户刷新他们的页面,依旧保存已登陆的用户信息是单页应用认证里面狡猾的一个环节。因为所有状态都存在客户端,刷新会清空用户信息。为了修复这个问题,我通常实现一个会返回已登陆的当前用户的数据的 API (比如 /profile),这个 API 会在 AngularJS 应用启动(比如在 “run” 函数)。然后用户数据会被保存在 Session 服务或者 $rootScope,就像用户已经登陆后的状态。或者,你可以把用户数据直接嵌入到 index.html,这样就不用额外的请求了。第三种方式就是把用户数据存在 cookie 或者 LocalStorage,但这会使得登出或者清空用户数据变得困难一点。
Das obige ist der detaillierte Inhalt vonDetaillierte Codebeispiele zur Verwendung von AngularJS zur Authentifizierung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!