Mvc5+ef6 Getting Started complete tutorial 11--the application of storage mode in MVC

Everyone has been waiting.

This topic focuses on the permissions scheme in MVC.

Permission control is a problem that every system must solve and is one of the most discussed topics in the garden.

In the previous series we used the Sysuser, Sysrole, Sysuserrole, which are examples of the sample tables.

Based on this, we complete the core functions of RBAC (role-based control).

Given my best practice here, the end result is that for any action or controller, you can control access based on the role you configure.

Once you have completed this core feature, you can extend common functionality in two ways:

1. Ability to control permissions based on the organization/user/role's set

2. Based on this core function, the dynamic configuration of the menu is realized.

This article will first complete the core function, the extension part of the content in the subsequent article again.

Article outline

• Overview Highlights
• Theoretical basis
• Detailed steps
• Summarize

Overview Essentials (Knowledge points)

First, MVC form authentication identity basis

Typical usage Examples:

1. Web.configàsystem.web configuration section, open form authentication

2. Add filtering on a control or action that requires authentication, such as restricting only Scott can access

There are two other common forms, namely:

The logged-on user can access

[Authorize]

Users with Admin role can access

[Authorize (Roles = "Admin")]

Filter conditions can be added to the action or the entire controller.

Second, MVC permission filter extension

It is obvious that there are two drawbacks in the above solution:

1. Modify the permissions in the action, controller on the modified after the need to recompile, inflexible.

2. Role in the filter is a built-in object that cannot be filtered by roles without using the integrated permissions scheme of ASP.

To solve these two problems, you just need to extend the class Authorizeattribute.

Theoretical basis

To enable the use of custom role control permissions, we need to extend or bypass the membership and role provider frameworks of ASP.

1. Extension: Implementation of custom Membership/role provider

2. Bypass: Do not use directly

We choose to bypass the way, so the words are more flexible.

(because if your character structure is inconsistent with the system, it's more cumbersome to use an extended approach.)

We use the form certification of the three core API, using only these APIs can reduce the workload, but also with the Membership/role provider to remain independent, fish and bear cake both.

1. Formsauthentication.setauthcookie

After the user logs in, specify the user name

2. request.isauthenticated

return true after login

3. HttpContext.Current.User.Identity.Name

Returns the user name of the login

The complete process of permission filtering:

1. Authetication (login)

After the login is successful, call Formsauthentication.setauthcookie to set a user name.

2. Authorization (Authorization)

New Custom Authorization Attribute class: Customauthorizeattribute (inherited from Authorizeatrribute), Extended rights filter

3. Similar to the default authorize attribute usage, additional custom authorize attribute to controller or action to implement permission filtering

Detailed steps

Here are the implementation steps.

First, enable form authentication, complete login/exit basic function

1. Enable form authentication

Web.configàsystem.web configuration section, enabling form authentication

2. Complete login/exit basic function

New Controller:accountcontroller

Login function:

Exit function

Corresponding view (please view the source file directly)

Second, prepare the permissions configuration file.

1. Basic data used: User, role and user/role relationship

2. Permission relationship for role and action

Here we first use an XML instead, and the subsequent final project will be unified into the DB when it is finished.

New Folder config, new actionroles file, configuring Action/role correspondence

Description

When action is not configured, access is granted by default;

The Action configuration role is empty and has access rights.

Iii. Expansion of Authorizeattribute

1. New class Customauthorizeattribute, inheritance and Authorizeattribute

Override two methods:

A. Called when authorization is requested:

B. Provide an entry point for custom authorization checks, via True

Specific implementation:

The implementation of the getactionroles used above:

Summarize

At this point, the entire process of permission control is OK, let's test it.

New HomeController, new action to do test (Index, About,contact)

Review the underlying data.

Scott role is General Users

The XML configuration is:

We add [customauthorize] to the whole homecontroller.

Examples of usage scenarios:

1. Index is configured to be empty and accessible to anyone

2. About configuration as manager, Administrators, General Users can access

Skip to login interface when not logged in

3. Contact configuration for administrators can access

Scott's role is General Users, not in the permissions table, login not in this page

Additional notes:

For example, you can set the global.

This allows you to apply a custom filter to all actions without requiring a single setting.

Welcome all comments and support, wish to learn progress:)

Mvc5+ef6 Getting Started complete tutorial 11--the application of storage mode in MVC