Shulou(Shulou.com)06/02 Report--

Based on how RBAC implements access control in front-end separation mode in Angular, it is believed that many inexperienced people are at a loss about this. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

RBAC role-based access control is common in the design of permissions. The basic idea is that various permissions for system operations are not directly granted to specific users, but to establish a role set between the set of users and the set of permissions. Each role corresponds to a corresponding set of permissions.

Once the user is assigned the appropriate role, the user has all operational permissions for that role. The advantage of this is that you don't have to assign permissions every time you create a user, just assign the corresponding role to the user, and the permission change of the role is much less than that of the user, which will simplify the rights management of the user and reduce the overhead of the system.

In single-page applications built by Angular, we need to do a few extra things to implement such an architecture. In terms of the overall project, there are about 3 areas that front-end engineers need to deal with.

1.UI processing (judging whether some content on the page is displayed according to the permissions the user has)

two。 Routing processing (when a user visits a url that he does not have permission to access, he jumps to a page with an error prompt)

3. HTTP request processing (when we send a data request, if the returned status is 401 or 401, we usually redirect to a page with an error prompt)

How to achieve it?

First of all, you need to get all the permissions of the current user before Angular starts, and then a more elegant way is to store this mapping through a service. For UI to deal with whether the content on a page is displayed according to permissions, we should use a directive to achieve. When we finish processing this, we also need to add an additional "permission" attribute to it when adding a route, and assign it a value indicating which roles have permissions to jump to the URL, and then use Angular to listen to routeChangeStart events to verify whether the current user has this URL access. * We also need a HTTP interceptor to monitor whether the status returned by a request is 401 or 403. Jump to an error page.

Generally speaking, this is the work, which seems to be a lot, but in fact it is easy to deal with one by one.

Get the mapping to permission before Angular runs

The Angular project starts through ng-app, but in some cases we want the Angular project to be under our control. For example, in this case, I want to get all the permission mappings of the currently logged-in user, and then start Angular's App. Fortunately, Angular itself provides this way, that is, angular.bootstrap ().

Var permissionList; angular.element (document) .ready (function () {$.get ('/ api/UserPermission', function (data) {permissionList = data; angular.bootstrap (document, ['App']);});})

People who watch carefully may notice that $. Get () is used here, and there is no misuse of jQuery instead of Angular's $resource or $http, because at this time Angular has not been started and its function cannot be used yet.

Further using the above code, you can put the obtained mapping into a service as a global variable.

/ / app.js var app = angular.module ('myApp', []), permissionList; app.run (function (permissions) {permissions.setPermissions (permissionList)}); angular.element (document) .ready (function () {$.get (' / api/UserPermission', function (data) {permissionList = data; angular.bootstrap (document, ['App']);});}) / / common_service.js angular.module ('myApp') .factory (' permissions', function ($rootScope) {var permissionList; return {setPermissions: function (permissions) {permissionList = permissions; $rootScope.$broadcast ('permissionsChanged')}};})

After getting the permission set of the current user, we archive this set to a corresponding service, and then do two more things:

(1) storing permissions in factory variable, keeping it in memory all the time, realizing the function of global variable, but not polluting the namespace.

(2) broadcast events through $broadcast when permissions are changed.

How to determine the visibility and concealment of UI components based on permissions

Here we need to write a directive that shows or hides elements according to permission relationships.

{{name}} {{name}}

The ideal situation here is to pass a has-permission attribute to verify the name of permission, show it if the current user has it, and hide it if not.

Angular.module ('myApp'). Directive (' hasPermission', function (permissions) {return {link: function (scope, element, attrs) {if (! _ .isString (attrs.hasPermission)) throw "hasPermission value must be a string"; var value = attrs.hasPermission.trim (); var notPermissionFlag = value [0] = ='!'; if (notPermissionFlag) {value = value.slice (1). Trim () } function toggleVisibilityBasedOnPermission () {var hasPermission = permissions.hasPermission (value); if (hasPermission & &! notPermissionFlag | |! hasPermission & & notPermissionFlag) element.show (); else element.hide ();} toggleVisibilityBasedOnPermission (); scope.$on ('permissionsChanged', toggleVisibilityBasedOnPermission);}};})

Extend the previous factory:

Angular.module ('myApp') .factory (' permissions', function ($rootScope) {var permissionList; return {setPermissions: function (permissions) {permissionList = permissions; $rootScope.$broadcast ('permissionsChanged')}, hasPermission: function (permission) {permission = permission.trim () Return _ .some (permissionList, function (item) {if (_ .isString (item.Name)) return item.Name.trim () = permission});};})

Privileged access on the route

The idea of implementing this part is as follows: when we define a route, we add an attribute of permission, and the value of the attribute is what permissions we have to access the current url. Then listen for url changes all the time through routeChangeStart events. Each time you change the url, check whether the current url to be redirected meets the criteria, and then decide whether to jump successfully or to the wrong prompt page.

Router.js:

App.config (function ($routeProvider) {$routeProvider. When ('/', {templateUrl: 'views/viewCourses.html', controller:' viewCoursesCtrl'}). When ('/ unauthorized', {templateUrl: 'views/error.html', controller:' ErrorCtrl'}). When ('/ courses/:id/edit', {templateUrl: 'views/editCourses.html' Controller: 'editCourses', permission:' Edit'}) })

MainController.js or indexController.js (in short, parent layer Controller)

App.controller ('mainAppCtrl', function ($scope, $location, permissions) {$scope.$on (' $routeChangeStart', function (scope, next, current) {var permission = next.$$route.permission; if (_ .isString (permission) & &! permissions.hasPermission (permission)) $location.path ('/ unauthorized');})

The previously written hasPermission is still used here, and these things are highly reusable. This is done. Before each route jump of view, just judge whether it has the permission to jump or not in the Controller of the parent container.

HTTP request processing

This should be relatively easy to handle, and the way of thinking is also very simple. Because Angular applications recommend RESTful-style excuses, the use of the HTTP protocol is clear. If the status code returned by the request is 401 or 403, it means there is no permission, just jump to the corresponding error prompt page.

Of course, we can't manually verify and forward every request, so we definitely need a total filter. The code is as follows:

Angular.module ('myApp') .config (function ($httpProvider) {$httpProvider.responseInterceptors.push (' securityInterceptor')) Provider ('securityInterceptor', function () {this.$get = function ($location, $Q) {return function (promise) {return promise.then (null, function (response) {if (response.status = 403 | | response.status = 401) {$location.path (' / unauthorized');} return $q.reject (response);}) };)

Write here can almost achieve in this front-end separation mode, the front-end part of the rights management and control.

After reading the above, have you mastered the method of access control in Angular based on RBAC in front-end separation mode? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.