Under normal circumstances, when we do access rights management, we will save the basic information of the user after the correct login in the session, and get it every time the user requests page or interface data in the future
Session to see and compare whether he is logged in and whether he can access the current page.
The principle of Session is to generate a SessionID on the server side corresponding to the stored user data, and the SessionID is stored in a cookie, and the client will carry this with it every time it is requested
Cookie, the server finds the data stored on the server side based on the session ID in the cookie.
FormsAuthentication is provided by Microsoft for us developers to use for authentication. Through this authentication, we can store the user name and some user data in cookies,
Basic identity and role authentication can be easily achieved through basic condition settings.
The effect to be achieved here is to implement role-based access control using the system-provided Authorize without using membership.
1. Create a Ticket
After the user logs in, the user's ID and corresponding role (for multiple roles, separated) are stored in the ticket.
Encrypt the ticket with FormsAuthentication.Encrypt.
Store the encrypted ticket in the Response cookie (the client js does not need to read this cookie, so it is best to set HttpOnly=True to prevent browser attacks from stealing and forging cookies). This way, you can read it from the Request cookie next time.
A simple demo is as follows:
bool isPersistent, //whether to persist (set as needed, if set to persistence, the Expires setting of the cookie must be set when sending a cookie)
The sixth parameter of FormsAuthenticationTicket stores the userData of type string, where the role ID of the current user is stored, separated by a comma.
When logging in with a username "test", a log cookie appears on the client
2. Obtain certification information
After logging in, on the content page, we can obtain the uname information through the User.Identity.Name of the current request, or we can decrypt the cookie in the request to obtain the ticket, and then obtain the uname and userData (that is, the previously stored role ID information) from it.
3. Realize permission access control through annotation attributes
Configure Enable Form Authentication and Role Management in web.config
When we add annotation properties to Controller and Action, where do we get the set Role? Since we don't use the Membership-based authentication, we're also going to create a custom RoleProvider. The name is CustomRoleProvider, which is inherited from RoleProvider. Here is the creation of your own CustomRoleProvider.cs file in the Helper folder under the MVCApp.
There are many abstract methods in RoleProvider, and we only implement the GetRolesForUser method to get user roles. The user role here can be queried from the database according to the user ID obtained, or the one stored in the session or stored in the cookie. Here I have already stored the role in the userData of the ticket, so let's get it from the ticket.
If necessary, add annotation attributes to the validated Controller or Action, for example, this Action only allows access with a RoleID of 1 or 2 or 3, and the current user RoleID is (7, 1, 8), which means the user has the right to access.
P.S. :1. Ticket is stored at the cookie expiration time, and if the browser is closed to remember the current ticket, the parameters can be set when the FormsAuthenticationTicket is instantiated.
2. The acquisition of Role can be read directly from the database without being stored in the userData of the ticket, and the userData can store other information.
3. If you want to flexibly configure the Controller and Action's Allowed Access Roles, you can customize the OnAuthorization method in the AuthorizeAttribute override, in which the method is used
Read the role ID that is allowed on the current page and check it according to the current user's RoleID. In this way, the flexible configuration of the role is realized.
4. The information in the ticket is ultimately stored in the cookie, and the security is still at your own discretion, I personally think it is better to store the UserID and RoleID in the session.
|
Posted on 7/19/2018 5:31:14 PM
|
|
|
