ABP框架 - 授权
本节内容:
几乎所有的企业应用在某引起级别上使用授权。授权用来验证一个用户是否允许应用里的某些指定操作。
ABP定义了一个基于许可的基础构架来实现授权。
授权系统使用IPermissionChecker来检查许可,虽然你用自己的方式实现它,不过在module-zero项目里已完全实现。如果没有实现该接口,会使用NullPermissionChecker,它给每个人授予所有许可。
为每个操作定义的唯一许可必须得到授权,为使用许可要先定义一个,ABP是按模块化设计的,所以不同的模块可以拥有不同的许可,一个模块为了定义它的许可,应当创建一个继承AuthorizationProvider的类。授权供应器示例如下:
public class MyAuthorizationProvider : AuthorizationProvider { public override void SetPermissions(IPermissionDefinitionContext context) { var administration = context.CreatePermission("Administration"); var userManagement = administration.CreateChildPermission("Administration.UserManagement"); userManagement.CreateChildPermission("Administration.UserManagement.CreateUser"); var roleManagement = administration.CreateChildPermission("Administration.RoleManagement"); } }
IPermissionDefinitionContext拥有获取和创建许可的方法。
一个许可包含一些属性:
- Name:一个系统域内的唯一名称,用一个字符串常量,不用可变的字符串,是一个好的做法。在分级里我们更喜欢用.(点)号来命名,但它不是必须的,你设置为你喜欢的名称,唯一的规则是一定要唯一。
- DisplayName:一个本地化的用来之后在UI上显示许可的文本。
- Description:一个本地化的用来之后在UI上显示许可描述的文本。
- MultiTenancySides:在多租户应用里,许可可被租户或宿主使用,这是一个标记性的枚举,所以一个许可可同时被租户和宿主使用。
- DependedFeature:用来表明一个对Feature(特色)的依赖,所以这个许可只有在满足Feature(特色)依赖时才会被允许。
一个许可可以有一个父许可和多个子许可,虽然这对于许可检查没有什么作用,但可能有助于在UI上组织许可。
创建一个授权供应器之后,我们应当在我们模块的预初始化方法里注册它:
Configuration.Authorization.Providers.Add<MyAuthorizationProvider>();
授权供应器被自动注册到依赖注入里,所以一个授权供应器可以注入任何的依赖(如一个仓储),从而可以使用其它的源来定义许可。
检查许可
AbpAuthorize(AbpMvcAuthorize用于Mvc控制器,AbpApiAuthorize用于Web Api控制器)特性,是使用许可最简单也是最常用的方式。假设有一个应用服务方法如下所示:
[AbpAuthorize("Administration.UserManagement.CreateUser")] public void CreateUser(CreateUserInput input) { //A user can not execute this method if he is not granted for "Administration.UserManagement.CreateUser" permission. }
CreateUser方法不能被没有“Administration.UserManagement.CreateUser”许可的用户调用。
AbpAuthorize特性也检查当前用户是否已登录(使用IAbp.Session.UsrId),所以,如果我们为一个方法声明一个AbpAuthorize,它只用来检查用户是否已登录:
[AbpAuthorize] public void SomeMethod(SomeMethodInput input) {
//用户如果未登录,不能执行这个方法 }
ABP为授权使用强大的动态方法拦截,所以对于使用AbpAuthorize特性的方法有些限制:
- 不能用于私有方法。
- 不能用于静态方法。
- 不能用于无注入的类里的方法(我们必须使用依赖注入)。
同时,可用于:
- 任何通过接口调用的public方法(如通过接口使用应用服务)。
- 一个直接通过类引用(如Asp.Net Mvc或Web Api控制器)调用的virtual方法。
- 一个protected virtual方法。
注意:有4类授权特性:
- 在一个应用服务里(应用层)里,我们使用Abp.Authorization.AbpAuthorize特性。
- 在一个Mvc控制器(web层)里,我们使用Abp.Web.Mvc.Authorization.AbpMvcAuthorize特性。
- 在一个Asp.net Web Api里,我们使用Abp.WebApi.Authorization.AbpApiAuthorization特性。
- 在一个Asp.net Core里,我们使用Abp.AspNetCore.Mvc.Authorization.AbpMvcAuthorize特性。
这些不同来自于继承,在应用层里,ABP完整地实现了,也没有扩展任何类,但是在Mvc和Web Api里,它从自身框架的Authorize特性继承。
我们可以为应用服务添加AbpAllowAnonymous特性来禁用一个方法/类的授权,使用框架自身的AllowAnonymous特性来禁用Mvc、Web Api、Asp.net Core控制器的授权。
尽管AbpAuthorize特性能完美应对大部分情况,但有些情况我们必须要在方法内检查一个许可,这时我们可以注入并使用IPermissionChecker,如下所示:
public void CreateUser(CreateOrUpdateUserInput input) { if (!PermissionChecker.IsGranted("Administration.UserManagement.CreateUser")) { throw new AbpAuthorizationException("You are not authorized to create user!"); }
//一个用户如果没有经过“Administration.usermanagerment.CreateUser”许可的允许,是不可以到达这里的。 }
尽管IsGranted只是简单的返回true或false,但你也可以编写任何逻辑(IsGranted也有异步版本)。如果你像上面那样,只是简单的检查一个许可并抛出一个异常,你可以使用Authorize方法:
public void CreateUser(CreateOrUpdateUserInput input) { PermissionChecker.Authorize("Administration.UserManagement.CreateUser");
//一个用户如果没有经过“Administration.usermanagerment.CreateUser”许可的允许,是不可以到达这里的。
}
由于授权的广泛使用,ApplicationService和一些通用的基类注入并定义了PermissionChecker属性,因此,在应用服务类里,不需要注入就可以使用许可检查器。
基视图类已经定义了IsGranted方法来检查当前用户是否有许可证,因此,我们可以有条件的渲染视图,例如:
@if (IsGranted("Administration.UserManagement.CreateUser")) { <button id="CreateNewUserButton" class="btn btn-primary"><i class="fa fa-plus"></i> @L("CreateNewUser")</button> }
在客户端里,我们可以使用定义在abp.auth命名空间里的API,大部分情况下,我们需要检查当前用户是否有一个指定的许可(使用许可名称),例如:
abp.auth.isGranted('Administration.UserManagement.CreateUser');
你也可以使用abp.auth.grantedPermissions获取所有授予权限或abp.auth.allPerssions获取所有可用的许可名称。在运行时里查看abp.auth命名空间的其它API。
我们可能会用到许可的定义,这里可以注入并使用IPermissionManager。
kid1412声明:转载请把此段声明完整地置于文章页面明显处,并保留个人在博客园的链接:http://www.cnblogs.com/kid1412/(可点击跳转)。