ABP Application Layer--Permission validation

ABP Application Layer--Permission validation

The ABP is "ASP. Boilerplate Project (ASP. NET Template project) "for short.

ABP's official website : http://www.aspnetboilerplate.com

ABP's Open source project on GitHub : https://github.com/aspnetboilerplate

Almost all enterprise-class applications have different levels of permission validation. Permission validation is used to check whether a user allows certain specified actions. ABP has the infrastructure for you to implement permission validation.

Note: About the Ipermissionchecker interface

The ABP privilege system uses Ipermissionchecker to check for authorization. At the same time you can implement your own way as needed, and it is fully implemented in the Module-zero project. If Ipermissionchecker is not implemented, Nullpermissionchecker will be used to grant all permissions to everyone.

Define Permissions

Before using authentication permissions, we need to define unique permissions for each operation. ABP is designed based on modularity, so different modules can have different permissions. In order to define permissions, a module should create a derived class of Authorizationprovider. Myauthorizationprovider inherits from Authorizationprovider, in other words authorizationprovider derives myauthorizationprovider. Examples are as follows:

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 has a way to get and create permissions.

A permission has the following properties:

• Name: System-wide unique name. It's a good idea to define it as a string constant. We tend to put "." Split different levels, but it's not required. You can set any name you like. The only rule is that the name must be unique.
• Display Name: Use a localized string to show permissions to the UI.
• Description: Similar to display name.
• Isgrantedbydefault: Whether this permission is granted to (logged in) all users unless the display is specified. is usually set to False (the default value).
• Multitenancysides: For a tenant application, a permission can be based on the tenant or host (original: host). This is an enumeration identifier, so permissions can be applied to different aspects (original: Both Sides).
• A permission can have both parent and child permissions. Of course, this does not affect permission checking, it is only good at the UI layer to categorize permissions. After creating the Authorizationprovider, we should register it in the module's Preintialize method. As follows:

Configuration.authorization.providers.add<myauthorizationprovider> ()

The Authorizationprovider is automatically registered to the dependency injection system. Therefore, authorization provider can inject any dependency (like repository) to use other resources to create a permission definition.

Check Permissions

(1) using the Abpauthorize feature (using Abpauthorize attribute)

Abpauthorize (abpmvcauthorize corresponds to the MVC Controllers and abpapiauthorize Web API Controllers) feature is the simplest and most common way to check permissions. Please consider the following application service method:

[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.
}

Users who do not have the "Administration.UserManagement.CreateUser" permission cannot call CreateUser.

The Abpauthorize feature also checks whether the current user is logged on (using Iabpsession.userid). Therefore, if we declare a method to be a abpauthorize attribute, it will at least check whether the user is logged on. The code is as follows: [Abpauthorize]

public void SomeMethod(SomeMethodInput input)
{
    //A user can not execute this method if he did not login.
}

(2) Abpauthorize attribute description (abpauthorize attribute notes)

The ABP uses dynamic method interception for permission validation. Therefore, there are some limitations to the method of using the Abpauthorize attribute. As follows:

• cannot be applied to private method
• cannot be applied to static method
• cannot be applied to non-injected (non-injected) classes (we must use dependency injection).

In addition

• The Abpauthorize attribute can be applied to any public method if this method is called by an interface (for example, through an interface call in application services)
• Method is a virtual (virtual) method, if this method is called directly by a class reference (like an ASP. NET MVC or Web API Controller).
• The method is the virtual (virtual) method, if it is protected.

Note: There are three types of abpauthorize features:

• In application services (application layer), we use Abp.Authorization.AbpAuthorize;
• In the MVC controller (Web layer), we use Abp.Web.Mvc.Authorization.AbpMvcAuthorize;
• In the ASP. NET Web API, we use Abp.WebApi.Authorization.AbpApiAuthorize.

These three classes inherit from a different place.

• In MVC, it inherits from MVC's own authorize class.
• In the Web API, it inherits from the authorize class of the Web API. Therefore, it is best to inherit into MVC and the Web API.
• However, in the application layer, it is completely implemented by the ABP itself without any extension of the subclass.

(3) using Ipermissionchecker

Abpauthorize is suitable for most situations, but in some cases, we still need to perform authorization validation in the method body. We can inject and use Ipermissionchecker objects. As shown in the code below:

public void CreateUser(CreateOrUpdateUserInput input)
{
    if (!PermissionChecker.IsGranted("Administration.UserManagement.CreateUser"))
    {
        throw new AbpAuthorizationException("You are not authorized to create user!");
    }

    //A user can not reach this point if he is not granted for "Administration.UserManagement.CreateUser" permission.
}


	

Of course, you can write any logic, because the Isgranted method simply returns True or FALSE (it also has an asynchronous version of OH). If you simply check a permission and throw an exception as in the above code, you can use the authorize method:

public void CreateUser(CreateOrUpdateUserInput input)
{
    PermissionChecker.Authorize("Administration.UserManagement.CreateUser");

    //A user can not reach this point if he is not granted for "Administration.UserManagement.CreateUser" permission.
}

Because permission validation is typically implemented with the application layer, the Applicationservice base class injects and defines the PermissionChecker attribute. Therefore, the Permission Checker allows you to use the Application service class without the need for display injection.

I hope that more domestic architects will be able to focus on the ABP project, and perhaps it will help you, perhaps with your participation, this project can develop better.

Welcome to add ABP Architecture Design Exchange QQ Group: 134710707

Click here to go to the ABP series articles General Catalogue

ABP Application Layer--Permission validation