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