AngularJS中实现权限控制 - 基于RBAC

权限的设计中比较常见的就是RBAC基于角色的访问控制,基本思想是,对系统操作的各种权限不是直接授予具体的用户,而是在用户集合与权限集合之间建立一个角色集合。每一种角色对应一组相应的权限。

一旦用户被分配了适当的角色后,该用户就拥有此角色的所有操作权限。这样做的好处是,不必在每次创建用户时都进行分配权限的操作,只要分配用户相应的角色即可,而且角色的权限变更比用户的权限变更要少得多,这样将简化用户的权限管理,减少系统的开销。

在Angular构建的单页面应用中,要实现这样的架构我们需要额外多做一些事.从整体项目上来讲,大约有3处地方,前端工程师需要进行处理.

1. UI处理(根据用户拥有的权限,判断页面上的一些内容是否显示)

2. 路由处理(当用户访问一个它没有权限访问的url时,跳转到一个错误提示的页面)

3. HTTP请求处理(当我们发送一个数据请求,如果返回的status是401或者401,则通常重定向到一个错误提示的页面)

如何实现?

首先需要在Angular启动之前就获取到当前用户的所有的permissions,然后比较优雅的方式是通过一个service存放这个映射关系.对于UI处理一个页面上的内容是否根据权限进行显示,我们应该通过一个directive来实现.当处理完这些,我们还需要在添加一个路由时额外为其添加一个"permission"属性,并为其赋值表明拥有哪些权限的角色可以跳转这个URL,然后通过Angular监听routeChangeStart事件来进行当前用户是否拥有此URL访问权限的校验.最后还需要一个HTTP拦截器监控当一个请求返回的status是401或者403时,跳转页面到一个错误提示页面.

大致上的工作就是这些,看起来有些多,其实一个个来还是挺好处理的.

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

写到这里就差不多可以实现在这种前后端分离模式下,前端部分的权限管理和控制了。

时间: 2024-07-30 13:49:43

AngularJS中实现权限控制 - 基于RBAC的相关文章

AngularJS中在前后端分离模式下实现权限控制 - 基于RBAC

权限的设计中比较常见的就是RBAC基于角色的访问控制,基本思想是,对系统操作的各种权限不是直接授予具体的用户,而是在用户集合与权限集合之间建立一个角色集合.每一种角色对应一组相应的权限. 一旦用户被分配了适当的角色后,该用户就拥有此角色的所有操作权限.这样做的好处是,不必在每次创建用户时都进行分配权限的操作,只要分配用户相应的角色即可,而且角色的权限变更比用户的权限变更要少得多,这样将简化用户的权限管理,减少系统的开销. 在Angular构建的单页面应用中,要实现这样的架构我们需要额外多做一些事

使用Lync 2013 基于角色的权限控制:RBAC 给用户分配指定的操作权限

使用场景: 在大型的Lync统一沟通系统的日常运维中,我们需要为不同角色的管理员分配不同的Lync管理权限,在Lync Server 2013上面就使用了基于角色的权限控制:RBAC ,它里面分了多种权限角色,包括 CsAdministrator,CsUserAdministrator,CsVoiceAdministrator,CsServerAdministrator,CsViewOnlyAdministrator,CsHelpDesk等等,不同的角色有不同的Lync管理权限, 例如,当我们只

&lt;实训|第九天&gt;掌握linux中普通的权限控制和三种特殊的权限(sst),做合格的运维工程师

linux中,权限的学习是必不可少的,不论是作为一名运维工程师或者是单一的管理者,学习好linux中的权限控制,你就可以保护好自己的隐私同时规划好你所管理的一切. 权限的学习是很多的,不要认为自己已经把自己的隐私保护的很好,漏洞总是有的,侧面的攻击往往是难以防守的.所以大家跟我一起学习一下基础的权限控制,在后面也会有更多关于权限控制的知识点分享出来.谢谢各位的关注和支持!  开班第九天: 今天的课程大纲: linux系统中文件目录的基本权限控制 如何来修改默认的生成权限 三种特殊的权限(s,s,

django中的权限控制

Django默认提供了权限控制,但只能对使用了其自带的登录认证的用户进行权限控制,说白了就是只能对存储在auth_user表中的用户进行权限控制,但不能对未登录过的用户进行权限控制.但如果通过集成LDAP认证后的用户,其用户也会被缓存到该表中,即变相实现了AD用户也能进行权限控制. 权限是auth 应用中定义的Permission类型:User与Permission是many-to-many的关系. Django对于每个模型类,自动增加add.change.delete三种权限,以便于权限控制.

如何在 vue 中添加权限控制管理?---vue中文社区

前言 在一个项目中,一些功能会涉及到重要的数据管理,为了确保数据的安全,我们会在项目中加入权限来限制每个用户的操作.作为前端,我们要做的是配合后端给到的权限数据,做页面上的各种各样的限制. 需求 因为这是一个工作上的业务需求,所以对于我来说主要有两个地方需要进行权限控制. 第一个是侧边菜单栏,需要控制显示与隐藏. 第二个就是页面内的各个按钮,弹窗等. 流程 如何获取用户权限? 后端(当前用户拥有的权限列表)-> 前端(通过后端的接口获取到,下文中我们把当前用户的权限列表叫做 permission

&lt;实训|第十三天&gt;linux中ACL权限控制以及磁盘配额,附编译属于自己的linux内核

[[email protected]~]#序言 首先讲讲昨天关于缩容失败,开不机的解决方法:ACL权限也算是一个很重要的知识点,不难,但是很实用:磁盘配额一般不需要自己弄,但是要懂得原理.剩下的就是编译属于自己的linux内核,根据自己的需求不论是硬件还是其他,你都可以定制,但是编译成功与否这个我不敢保证,我也编译了两次才成功的.  开班第十三天: [[email protected]~]#今天的课程大纲 1.缩容失败原因以及开不了机解决方法 2.Linux中ACL权限的详解 3.讲解一下磁盘配

171.补充-在模板中添加权限控制

在模板中使用权限: 在settings.TEMPLATES.OPTIONS.context_process下,因为添加了django.auth.context_processors.auth上下文处理器,因此,在模板中可以直接通过perms来获取用户的所有权限,示例代码如下: <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title

CRM Transaction处理中的权限控制

当试图打开一个Opportunity时, 系统会进行如下一系列的权限检查: 1. 检查Authorization object CRM_ORD_OP: 此处会检查当前user的partner function和partner function category的设置情况: 如果检查失败,会抛出error message: 2. 进行第二轮针对CRM_ORD_LP的检查: 3. 如果再失败,进行第三轮对CRM_OPP的权限检查: 45代表Allow: 4. 如果再失败,进行第四轮对CRM_ORD_

SAP CRM Transaction处理中的权限控制

当试图打开一个Opportunity时, 系统会进行如下一系列的权限检查: 1. 检查Authorization object CRM_ORD_OP: 此处会检查当前user的partner function和partner function category的设置情况: 如果检查失败,会抛出error message: 2. 进行第二轮针对CRM_ORD_LP的检查: 3. 如果再失败,进行第三轮对CRM_OPP的权限检查: 45代表Allow: 4. 如果再失败,进行第四轮对CRM_ORD_