偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

Angular中在前后端分離模式下實(shí)現(xiàn)權(quán)限控制 - 基于RBAC

開(kāi)發(fā) 前端
權(quán)限的設(shè)計(jì)中比較常見(jiàn)的就是RBAC基于角色的訪(fǎng)問(wèn)控制,基本思想是,對(duì)系統(tǒng)操作的各種權(quán)限不是直接授予具體的用戶(hù),而是在用戶(hù)集合與權(quán)限集合之間建立一個(gè)角色集合。每一種角色對(duì)應(yīng)一組相應(yīng)的權(quán)限。

權(quán)限的設(shè)計(jì)中比較常見(jiàn)的就是RBAC基于角色的訪(fǎng)問(wèn)控制,基本思想是,對(duì)系統(tǒng)操作的各種權(quán)限不是直接授予具體的用戶(hù),而是在用戶(hù)集合與權(quán)限集合之間建立一個(gè)角色集合。每一種角色對(duì)應(yīng)一組相應(yīng)的權(quán)限。

一旦用戶(hù)被分配了適當(dāng)?shù)慕巧?,該用?hù)就擁有此角色的所有操作權(quán)限。這樣做的好處是,不必在每次創(chuàng)建用戶(hù)時(shí)都進(jìn)行分配權(quán)限的操作,只要分配用戶(hù)相應(yīng)的角色即可,而且角色的權(quán)限變更比用戶(hù)的權(quán)限變更要少得多,這樣將簡(jiǎn)化用戶(hù)的權(quán)限管理,減少系統(tǒng)的開(kāi)銷(xiāo)。

[[118146]]

在Angular構(gòu)建的單頁(yè)面應(yīng)用中,要實(shí)現(xiàn)這樣的架構(gòu)我們需要額外多做一些事.從整體項(xiàng)目上來(lái)講,大約有3處地方,前端工程師需要進(jìn)行處理.

1.UI處理(根據(jù)用戶(hù)擁有的權(quán)限,判斷頁(yè)面上的一些內(nèi)容是否顯示)

2. 路由處理(當(dāng)用戶(hù)訪(fǎng)問(wèn)一個(gè)它沒(méi)有權(quán)限訪(fǎng)問(wèn)的url時(shí),跳轉(zhuǎn)到一個(gè)錯(cuò)誤提示的頁(yè)面)

3. HTTP請(qǐng)求處理(當(dāng)我們發(fā)送一個(gè)數(shù)據(jù)請(qǐng)求,如果返回的status是401或者401,則通常重定向到一個(gè)錯(cuò)誤提示的頁(yè)面)

如何實(shí)現(xiàn)?

首先需要在Angular啟動(dòng)之前就獲取到當(dāng)前用戶(hù)的所有的permissions,然后比較優(yōu)雅的方式是通過(guò)一個(gè)service存放這個(gè)映射關(guān)系.對(duì)于UI處理一個(gè)頁(yè)面上的內(nèi)容是否根據(jù)權(quán)限進(jìn)行顯示,我們應(yīng)該通過(guò)一個(gè)directive來(lái)實(shí)現(xiàn).當(dāng)處理完這些,我們還需要在添加一個(gè)路由時(shí)額外為其添加一個(gè)"permission"屬性,并為其賦值表明擁有哪些權(quán)限的角色可以跳轉(zhuǎn)這個(gè)URL,然后通過(guò)Angular監(jiān)聽(tīng)routeChangeStart事件來(lái)進(jìn)行當(dāng)前用戶(hù)是否擁有此URL訪(fǎng)問(wèn)權(quán)限的校驗(yàn).***還需要一個(gè)HTTP攔截器監(jiān)控當(dāng)一個(gè)請(qǐng)求返回的status是401或者403時(shí),跳轉(zhuǎn)頁(yè)面到一個(gè)錯(cuò)誤提示頁(yè)面.

大致上的工作就是這些,看起來(lái)有些多,其實(shí)一個(gè)個(gè)來(lái)還是挺好處理的.

在Angular運(yùn)行之前獲取到permission的映射關(guān)系

Angular項(xiàng)目通過(guò)ng-app啟動(dòng),但是一些情況下我們是希望Angular項(xiàng)目的啟動(dòng)在我們的控制之中.比如現(xiàn)在這種情況下,我就希望能獲取到當(dāng)前登錄用戶(hù)的所有permission映射關(guān)系后,再啟動(dòng)Angular的App.幸運(yùn)的是Angular本身提供了這種方式,也就是angular.bootstrap().

  1. var permissionList;  
  2. angular.element(document).ready(function() {  
  3.   $.get('/api/UserPermission'function(data) {  
  4.     permissionList = data;  
  5.     angular.bootstrap(document, ['App']);  
  6.   });  
  7. }); 

看的仔細(xì)的人可能會(huì)注意到,這里使用的是$.get(),沒(méi)有錯(cuò)用的是jQuery而不是Angular的$resource或者$http,因?yàn)樵谶@個(gè)時(shí)候Angular還沒(méi)有啟動(dòng),它的function我們還無(wú)法使用.

進(jìn)一步使用上面的代碼可以將獲取到的映射關(guān)系放入一個(gè)service作為全局變量來(lái)使用.

  1. // app.js  
  2. var app = angular.module('myApp', []), permissionList;  
  3.     
  4. app.run(function(permissions) {  
  5.   permissions.setPermissions(permissionList)  
  6. });  
  7.     
  8. angular.element(document).ready(function() {  
  9.   $.get('/api/UserPermission'function(data) {  
  10.     permissionList = data;  
  11.     angular.bootstrap(document, ['App']);  
  12.   });  
  13. });  
  14.    
  15. // common_service.js  
  16. angular.module('myApp')  
  17.   .factory('permissions'function ($rootScope) {  
  18.     var permissionList;  
  19.     return {  
  20.       setPermissions: function(permissions) {  
  21.         permissionList = permissions;  
  22.         $rootScope.$broadcast('permissionsChanged')  
  23.       }  
  24.    };  
  25.   }); 

在取得當(dāng)前用戶(hù)的權(quán)限集合后,我們將這個(gè)集合存檔到對(duì)應(yīng)的一個(gè)service中,然后又做了2件事:

(1) 將permissions存放到factory變量中,使之一直處于內(nèi)存中,實(shí)現(xiàn)全局變量的作用,但卻沒(méi)有污染命名空間.

(2) 通過(guò)$broadcast廣播事件,當(dāng)權(quán)限發(fā)生變更的時(shí)候.

如何確定UI組件的依據(jù)權(quán)限進(jìn)行顯隱

這里我們需要自己編寫(xiě)一個(gè)directive,它會(huì)依據(jù)權(quán)限關(guān)系來(lái)進(jìn)行顯示或者隱藏元素.

  1. <!-- If the user has edit permission the show a link -->  
  2. <div has-permission='Edit'>  
  3.   <a href="/#/courses/{{ id }}/edit"> {{ name }}</a>  
  4. </div>  
  5.     
  6. <!-- If the user doesn't have edit permission then show text only (Note the "!" before "Edit") -->  
  7. <div has-permission='!Edit'>  
  8.   {{ name }}  
  9. </div> 

這里看到了比較理想的情況是通關(guān)一個(gè)has-permission屬性校驗(yàn)permission的name,如果當(dāng)前用戶(hù)有則顯示,沒(méi)有則隱藏.

  1. angular.module('myApp').directive('hasPermission'function(permissions) {  
  2.   return {  
  3.     link: function(scope, element, attrs) {  
  4.       if(!_.isString(attrs.hasPermission))  
  5.         throw "hasPermission value must be a string";  
  6.     
  7.       var value = attrs.hasPermission.trim();  
  8.       var notPermissionFlag = value[0] === '!';  
  9.       if(notPermissionFlag) {  
  10.         value = value.slice(1).trim();  
  11.       }  
  12.     
  13.       function toggleVisibilityBasedOnPermission() {  
  14.         var hasPermission = permissions.hasPermission(value);  
  15.     
  16.         if(hasPermission && !notPermissionFlag || !hasPermission && notPermissionFlag)  
  17.           element.show();  
  18.         else 
  19.           element.hide();  
  20.       }  
  21.       toggleVisibilityBasedOnPermission();  
  22.       scope.$on('permissionsChanged', toggleVisibilityBasedOnPermission);  
  23.     }  
  24.   };  
  25. }); 

擴(kuò)展一下之前的factory:

  1. angular.module('myApp')  
  2.   .factory('permissions'function ($rootScope) {  
  3.     var permissionList;  
  4.     return {  
  5.       setPermissions: function(permissions) {  
  6.         permissionList = permissions;  
  7.         $rootScope.$broadcast('permissionsChanged')  
  8.       },  
  9.       hasPermission: function (permission) {  
  10.         permission = permission.trim();  
  11.         return _.some(permissionList, function(item) {  
  12.           if(_.isString(item.Name))  
  13.             return item.Name.trim() === permission  
  14.         });  
  15.       }  
  16.    };  
  17.   }); 

#p#

路由上的依權(quán)限訪(fǎng)問(wèn)

這一部分的實(shí)現(xiàn)的思路是這樣: 當(dāng)我們定義一個(gè)路由的時(shí)候增加一個(gè)permission的屬性,屬性的值就是有哪些權(quán)限才能訪(fǎng)問(wèn)當(dāng)前url.然后通過(guò)routeChangeStart事件一直監(jiān)聽(tīng)url變化.每次變化url的時(shí)候,去校驗(yàn)當(dāng)前要跳轉(zhuǎn)的url是否符合條件,然后決定是跳轉(zhuǎn)成功還是跳轉(zhuǎn)到錯(cuò)誤的提示頁(yè)面.

router.js:

  1. app.config(function ($routeProvider) {  
  2.   $routeProvider  
  3.     .when('/', {  
  4.       templateUrl: 'views/viewCourses.html',  
  5.       controller: 'viewCoursesCtrl' 
  6.     })  
  7.     .when('/unauthorized', {  
  8.       templateUrl: 'views/error.html',  
  9.       controller: 'ErrorCtrl' 
  10.     })  
  11.     .when('/courses/:id/edit', {  
  12.       templateUrl: 'views/editCourses.html',  
  13.       controller: 'editCourses',  
  14.       permission: 'Edit' 
  15.     });  
  16. }); 

mainController.js 或者 indexController.js (總之是父層Controller)

  1. app.controller('mainAppCtrl'function($scope, $location, permissions) {  
  2.   $scope.$on('$routeChangeStart'function(scope, next, current) {  
  3.     var permission = next.$$route.permission;  
  4.     if(_.isString(permission) && !permissions.hasPermission(permission))  
  5.       $location.path('/unauthorized');  
  6.   });  
  7. }); 

這里依然用到了之前寫(xiě)的hasPermission,這些東西都是高度可復(fù)用的.這樣就搞定了,在每次view的route跳轉(zhuǎn)前,在父容器的Controller中判斷一些它到底有沒(méi)有跳轉(zhuǎn)的權(quán)限即可.

HTTP請(qǐng)求處理

這個(gè)應(yīng)該相對(duì)來(lái)說(shuō)好處理一點(diǎn),思想的思路也很簡(jiǎn)單.因?yàn)锳ngular應(yīng)用推薦的是RESTful風(fēng)格的借口,所以對(duì)于HTTP協(xié)議的使用很清晰.對(duì)于請(qǐng)求返回的status code如果是401或者403則表示沒(méi)有權(quán)限,就跳轉(zhuǎn)到對(duì)應(yīng)的錯(cuò)誤提示頁(yè)面即可.

當(dāng)然我們不可能每個(gè)請(qǐng)求都去手動(dòng)校驗(yàn)轉(zhuǎn)發(fā)一次,所以肯定需要一個(gè)總的filter.代碼如下:

  1. angular.module('myApp')  
  2.   .config(function($httpProvider) {  
  3.     $httpProvider.responseInterceptors.push('securityInterceptor');  
  4.   })  
  5.   .provider('securityInterceptor'function() {  
  6.     this.$get = function($location, $q) {  
  7.       return function(promise) {  
  8.         return promise.then(nullfunction(response) {  
  9.           if(response.status === 403 || response.status === 401) {  
  10.             $location.path('/unauthorized');  
  11.           }  
  12.           return $q.reject(response);  
  13.         });  
  14.       };  
  15.     };  
  16.   }); 

寫(xiě)到這里就差不多可以實(shí)現(xiàn)在這種前后端分離模式下,前端部分的權(quán)限管理和控制了,用問(wèn)題請(qǐng)和我留言.

原文鏈接:http://my.oschina.net/blogshi/blog/300595

責(zé)任編輯:林師授 來(lái)源: 頑Shi的博客
相關(guān)推薦

2022-05-27 10:40:04

前后端權(quán)限控制設(shè)計(jì)

2020-05-25 16:05:17

前端限控制設(shè)分離

2017-02-15 10:18:32

架構(gòu)前后端分離

2014-04-18 14:43:07

前后端分離NodeJS

2019-06-12 19:00:14

前后端分離AppJava

2021-06-16 08:05:14

centos nginx 后端

2022-04-06 07:50:57

JWT后端Spring

2023-02-08 16:29:58

前后端開(kāi)發(fā)

2016-09-21 10:11:19

2021-09-18 09:45:33

前端接口架構(gòu)

2022-01-07 07:29:08

Rbac權(quán)限模型

2020-09-25 11:50:12

前后端分離架構(gòu)Web

2021-10-20 18:21:18

項(xiàng)目技術(shù)開(kāi)發(fā)

2019-07-09 05:44:35

前后端分離架構(gòu)接口規(guī)范

2016-10-31 14:16:33

node前后端分離koa

2014-04-18 10:04:15

NodeJS前后端分離

2024-05-24 08:34:16

2010-08-24 09:32:13

Exchange201RBAC用戶(hù)權(quán)限

2024-10-17 09:14:24

RBAC模型管理

2016-08-22 13:31:05

前端架構(gòu)前后端分離
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)