AngularJS中在先後端分離模式下實現權限控制 - 基於RBAC

一：RBAC 百科解釋：

基於角色的訪問控制（Role-Based Access Control）做爲傳統訪問控制（自主訪問，強制訪問）的有前景的代替受到普遍的關注。在RBAC中，權限與角色相關聯，用戶經過成爲適當角色的成員而獲得這些角色的權限。這就極大地簡化了權限的管理。在一個組織中，角色是爲了完成各類工做而創造，用戶則依據它的責任和資格來被指派相應的角色，用戶能夠很容易地從一個角色被指派到另外一個角色。角色可依新的需求和系統的合併而賦予新的權限，而權限也可根據須要而從某角色中回收。角色與角色的關係能夠創建起來以囊括更普遍的客觀狀況。    

 

二：權限的設計

權限的設計中比較常見的就是RBAC基於角色的訪問控制,基本思想是，對系統操做的各類權限不是直接授予具體的用戶，而是在用戶集合與權限集合之間創建一個角色集合。每一種角色對應一組相應的權限。

    一旦用戶被分配了適當的角色後，該用戶就擁有此角色的全部操做權限。這樣作的好處是，沒必要在每次建立用戶時都進行分配權限的操做，只要分配用戶相應的角色便可，並且角色的權限變動比用戶的權限變動要少得多，這樣將簡化用戶的權限管理，減小系統的開銷。

    在Angular構建的單頁面應用中,要實現這樣的架構咱們須要額外多作一些事.從總體項目上來說,大約有3處地方,前端工程師須要進行處理.

    1. UI處理(根據用戶擁有的權限,判斷頁面上的一些內容是否顯示)

    2. 路由處理(當用戶訪問一個它沒有權限訪問的url時,跳轉到一個錯誤提示的頁面)

    3. HTTP請求處理(當咱們發送一個數據請求,若是返回的status是401或者401,則一般重定向到一個錯誤提示的頁面)

 

三：數據庫設計

menu_info:菜單信息表，主要是定義一些頁面信息。

role_info：角色信息表，主要是定義一些角色。

role_menu:角色菜單表，主要是角色和菜單的映射，那些角色擁有那些菜單的權限。

user_info:用戶信息表，定義用戶信息。

role_user:角色用戶表，那個用戶擁有那些角色

若是創建一個用戶admin，首先要給他分配角色信息，而後再給角色分配菜單信息。這樣用戶在登陸頁面時，才能看到對應

的菜單信息。

 

四：實現

 1：首先須要在Angular啓動以前就獲取到當前用戶的全部的permissions,而後比較優雅的方式是經過一個service存放這個映射關係.對於UI處理一個頁面上的內容是否根據權限進行顯示,咱們應該經過一個directive來實現.當處理完這些,咱們還須要在添加一個路由時額外爲其添加一個"permission"屬性,併爲其賦值代表擁有哪些權限的角色能夠跳轉這個URL,而後經過Angular監聽routeChangeStart事件來進行當前用戶是否擁有此URL訪問權限的校驗.最後還須要一個HTTP攔截器監控當一個請求返回的status是401或者403時,跳轉頁面到一個錯誤提示頁面，大體上的工做就是這些,看起來有些多,其實一個個來仍是挺好處理的.

2：在web項目中通常在angular啓動時，就會發送請求，獲取當前用戶擁有那些角色，角色對應那些菜單訪問權限，放到一個數組中，當咱們訪問這個菜單時，

angular監聽routeChangeStart事件就會驗證當前訪問菜單是否在以前加載的數組中，是，則跳轉到定義的頁面，否，則跳轉到錯誤提示頁面。

3：在Angular運行以前獲取到permission的映射關係，Angular項目經過ng-app啓動,可是一些狀況下咱們是但願Angular項目的啓動在咱們的控制之中.好比如今這種狀況下,我就但願能獲取到當前登陸用戶的全部permission映射關係後,再啓動Angular的App.幸運的是Angular自己提供了這種方式,也就是angular.bootstrap().

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

 看的仔細的人可能會注意到,這裏使用的是$.get(),沒有錯，用的是jQuery而不是Angular的$resource或者$http,由於在這個時候Angular尚未啓動,它的function咱們還沒法使用.

  進一步使用上面的代碼能夠將獲取到的映射關係放入一個service做爲全局變量來使用.

// 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')
      }
   };
  });

 

    在取得當前用戶的權限集合後,咱們將這個集合存檔到對應的一個service中,而後又作了2件事:

    (1) 將permissions存放到factory變量中,使之一直處於內存中,實現全局變量的做用,但卻沒有污染命名空間.

    (2) 經過$broadcast廣播事件,當權限發生變動的時候.

 

    如何肯定UI組件的依據權限進行顯隱

    這裏咱們須要本身編寫一個directive,它會依據權限關係來進行顯示或者隱藏元素.

<!-- If the user has edit permission the show a link -->
<div has-permission='Edit'>
  <a href="/#/courses/{{ id }}/edit"> {{ name }}</a>
</div>
 
<!-- If the user doesn't have edit permission then show text only (Note the "!" before "Edit") -->
<div has-permission='!Edit'>
  {{ name }}
</div>

 

    這裏看到了比較理想的狀況是通關一個has-permission屬性校驗permission的name,若是當前用戶有則顯示,沒有則隱藏.

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);
    }
  };
});

 

    擴展一下以前的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
        });
      }
   };
  });

 

 

    路由上的依權限訪問

    這一部分的實現的思路是這樣: 當咱們定義一個路由的時候增長一個permission的屬性,屬性的值就是有哪些權限才能訪問當前url.而後經過routeChangeStart事件一直監聽url變化.每次變化url的時候,去校驗當前要跳轉的url是否符合條件,而後決定是跳轉成功仍是跳轉到錯誤的提示頁面.

    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 或者 indexController.js (總之是父層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');
  });
});

 

    這裏依然用到了以前寫的hasPermission,這些東西都是高度可複用的.這樣就搞定了,在每次view的route跳轉前,在父容器的Controller中判斷一些它到底有沒有跳轉的權限便可.

 

    HTTP請求處理

    這個應該相對來講好處理一點,思想的思路也很簡單.由於Angular應用推薦的是RESTful風格的藉口,因此對於HTTP協議的使用很清晰.對於請求返回的status code若是是401或者403則表示沒有權限,就跳轉到對應的錯誤提示頁面便可.

    固然咱們不可能每一個請求都去手動校驗轉發一次,因此確定須要一個總的filter.代碼以下:

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);
        });
      };
    };
  });

 

    寫到這裏就差很少能夠實如今這種先後端分離模式下,前端部分的權限管理和控制了

文章出處：http://www.open-open.com/lib/view/open1408084201582.html