The permission system is universal, take shrio as an example

Be careful when doing permissions

(a), display control,

Folders and pages are rendered according to the permissions of the user's login (you can log in, see how to integrate)

On the other hand: Pages---permissions control access,

All the controllers of the button inherit an abstract parent controller. Here, the user's button permissions are checked every time. The page uses the EL tag to determine whether to display it or not. At the same time, the permissions are controlled (to prevent direct clicks on the connection)

Display control (folder to button) The abstract parent class uses a method to query the current role, the button of the menu, and call it when jumping to the list. As for the display of the page folder, just find the set when the login is successful.

(2), access control (pages, buttons), permission configuration

Request---url controlled---get whether to require login, role, and permission. When entering the verification later, the url is not included, and then the corresponding method is called with the required requirements.

For example, authentication, authorization (here is also a direct match to the role permission requirements brought over)

1. User authentication

2. Organizational user roles and permissions

3. Configure all user role permissions in the system (here is protected)

4, shrio automatically releases two matches

5. To access a resource, first check whether it is controlled (3) (as long as it is controlled, the role and permission he needs will be automatically brought to the back according to 3), if it is controlled, pass 1, then 2, and when it reaches 4, it will be 2 and this access url brought over

The role and permission match determines whether to release or not. The same is true for security. If the url is not in the permission list initialized by the system, such as (3), it will not be intercepted by the permission system.

That is, only the accessed resources will be intercepted by shrio in 3. Each interception will reload the role of the current user, and then compare

Assemble the token, info, and verify it later

Authorize

AuthorizingRealm

getAuthorizationInfo

The shrio filter is automatically executed on each visit, 1,

role, permission match to decide whether to release, so does security

Of course, all urls and role information must be loaded at startup

authc, roles, perms (corresponding to addROle, addPermiss() in 1 and 2 respectively) indicate that these tests need to be passed

simpleAuthorInfo.addRole("admin");// Add a role to prove that the user has the admin role, equivalent to roles[admin]----roles default filter

simpleAuthorInfo.addStringPermission("admin:manage");// Adding permission is equivalent to perms[admin:manage], ":" indicates which permission is under which ----perms default filter

simpleAuthorInfo.addRoles(roleList);// Set roles for the current user Equivalent to roles[,,,,]

simpleAuthorInfo.addStringPermissions(permissionList);// Set permissions for the current user oper

Use any permission framework

1. Use his own submit url (form)---at this time, as long as the field name of the login form is consistent with the specification, the framework can automatically obtain the comparison

2. Use your own submission url (form), then the part that uses the permission framework needs to pass in parameters in this login method

3. When you need to customize the framework, you can refer to the existing writing. For example: RolesAuthorizationFilter//This is only released when all the parameters in roles[,,] match. If we need to match one, we can rewrite one

The implementation is as followshttp://blog.csdn.net/ikaraide/article/details/37928389

It should be noted that the resource of shrio is url, because when requesting, shrio compares the url of this request with the resource map we loaded for the first time (this url is excluding parameters, so all urls except edit (add, modify) are If you want a different name, it will usually be different

, because there are module names and operation names (such as Springmvc-style Lujin))

When accessing the upper page, the buttons are all in front of the same level of resources, and whether they can be accessed directly by the role control, because our users have the page and the access information of the button after they have the role.

perms is under the role, more fine-grained control

Notice:

1, log out and call the method of logging out of the framework (clear information, no public login method)

2. The login page will only verify authc, and it is useless to add other (roles, permissions) later, and will not be executed

3. Make your own filter. For example, you can access as long as a role is satisfied, refer to the RolesAuthorizationFilter of the system (the system uses this by default, and can only be accessed if all role parameters are satisfied)

4. The problem of reloading the entire resource-permission list (in order to not restart after modification, just look at how to call this method in the source code)

shrio dynamically update permissions

http://zgzty.blog.163.com/blog/static/83831226201361134047834/

<propertyname="filterChainDefinitions"value="#{authService.loadFilterChainDefinitions()}"/> This is in the original text format

http://blog.csdn.net/eggtk/article/details/38255871

http://blog.csdn.net/z971829916/article/details/22572587 This is organized according to the map

Dynamically create filterchaindefinitions, this is good

Possible formatting text tricks:

public static final String PREMISSION_STRING="perms[\"{0}\"]";

String q=MessageFormat.format(PREMISSION_STRING, "q");

perms["q"]

AuthenticationRealm will go as long as shrio is configured

As for whether it is a positive interception, see if this resource does not require AuthenticationFilter to see if this url resource is not configured

/admin/** = anon does not have to be logged in

/main**=authc only after successful login

/ui/info**=authc

/ui/listUser**=authc,perms[admin:manage] The login is successful, and it conforms to the admin role of the interceptor perms

If there is a match above, it will not go down

<map>

</map>

</property>

// permission rules

http://www.cppblog.com/guojingjia2006/archive/2014/05/14/206956.html here are the configuration permission rules and default filters

For example perms is the default filter

FormAuthenticationFilter authc is also the default filter that can be rewritten to pass project-specific parameters

@see 4) Give a few examples

* @see /admin=authc,roles[admin] (role) Indicates that the user must be authenticated and have the admin role to initiate a '/admin' request normally

* @see /edit=authc,perms[admin:edit] (permission) Indicates that the user must be authenticated and have the admin:edit permission to initiate a '/edit' request normally

* @see /home=user means that the user does not necessarily need to have been authenticated, as long as the login status has been remembered by Shiro, the '/home' request can be initiated normally

@see /admins/user/**=ssl No parameter, indicating a secure URL request, the protocol is https////////////////shrio and security can specify which ones need http, Which ones require https, and similar ports can also be specified

* @see parameters can be written multiple times, quotes must be added when multiple, and the parameters are separated by commas, such as /admins/user/**=roles["admin,guest"]m

* @see When there are multiple parameters, each parameter must be passed to pass, which is equivalent to the hasAllRoles() method

* @see parameters can be written multiple times, quotes must be added when multiple parameters, and the parameters are separated by commas, such as /admins/user/**=perms["user:add:*,user:modify:*"]

* @see When there are multiple parameters, each parameter must be passed to pass, which is equivalent to the isPermitedAll() method

2. Use the logout filter provided by shiro, //////////////////////////other filters do not need to be declared, it is the default filter that needs to be statement

Need to define the corresponding bean

</bean>

Then configure the corresponding url filter to logout as follows

<value>

# some example chain definitions:

/index.htm = anon

/logout = logout

/unauthed = anon

/console/** = anon

/css/** = anon

/js/** = anon

/lib/** = anon

/admin/** = authc, roles[admin]

/docs/** = authc, perms[document:read]

/** = authc

# more URL-to-FilterChain definitions here

</value>

The permission system is universal, take shrio as an example

Guess you like