[Shiro] Permission string and related content of authentication and authorization

1. Permission string

1. Format

Resource:Permission:Operation
(common format is:Module:Function:Operation）

1. Resources: refers to the objects, data or services that need to be protected in the system. A resource can be a general term or a specific object.
2. Permissions: Refers to the operations or functions on resources , which are used to limit the access and use of resources. Permission can be a verb or a descriptive word. Need to represent exactly what the permission does or does.
3. Operation: Refers to the execution of specific actions corresponding to a certain permission , such as CRUD.

Wildcards ( *) represent one or more.

Simple wildcards can also be used, for example sys:user:*, it is recommended to omit as sys:user(asterisks cannot be used to separate the front end).
Example 1 willsys:user successfully match all permission strings starting with or . Example 2 will successfully match all permission strings starting with orsys:usersys:user:
syssyssys:

2. Specific examples

Module:Function:Operation
Example 1: sys:user:editDelegateSystem Module: User Function: Edit Operation
Example 2: report:couponReceive:*RepresentativeReport module: coupon collection function: all operations

3. Other separators

1. Using "/" as a separator
   A hierarchical path that shows how permissions are divided between resources.
   For example,posts/view/read

2. Using "." as a delimiter
   is typically appropriate for systems with well-defined object or resource hierarchies, making permissions more like hierarchical components or namespaces.
   For example,posts.view.read

Doubt: The above 3 forms ( :, /, .), which separator should be used in actual development?
Answer: Personal understanding , you can use either one, mainly based on how the system was defined at the beginning, and you can use whichever you want.

2. Relevant content of authentication and authorization

1. The difference between authority, URI, and URL

• Permission (permission): Among other separators, "/" is used as a separator, which is very similar to the style of URL and URI, but it is mainly used as a string of permissions.
• URI : Uniquely identifies a resource.In filterChainDefinitionMap , the URI can be either the address of the backend request or the path of the static resource。

URI wildcards:
1. ?: Match one character. 【An arbitrary character】
2. *: Match zero or more character strings. 【Arbitrary path】
3. **: Match zero or more paths in the path. 【Arbitrary path and subpath】

Notice:

What is written above is URI (uniform resource identifier) , not URL (uniform resource locator) . There is a difference between the two:
URL is a specific URI, which is a subset of URI. It not only uniquely identifies resources, but also Provides information for locating this resource. URI is a semantic abstract concept, which can be absolute or relative, while URL must provide enough information to locate and is absolute.

Simply put:
URI : ID number (you can only know that there is such a person, but you don’t know who it is)
URL : ID address + name (not only know who this person is, but also find him)
as long as it can uniquely represent the resource It is URI, and the access method of its resources is given on the basis of URI is URL.
The above reference:
The difference and connection between URI and URL

In actual development, permission (permission) and URI are used in combination.

@Bean
public FilterChainDefinitionMap createFilterChainDefinitionMap() {
    
    
    Map<String, String> filterChainMap = new LinkedHashMap<>();
    filterChainMap.put("/public/**", "anon");
    filterChainMap.put("/admin/**", "authc,roles[admin]");
    filterChainMap.put("/**", "authc");
    return new DefaultFilterChainDefinitionMap(filterChainMap);
}

In the above example, we set the URI under /public/**the path to be accessible without authentication ( anon), set the URI under the path
to require authentication and permission to access ( ), and set the URI under all other paths to require Authentication is required to access ( )./admin/**adminauthc,roles[admin]
authc

2. Authentication and authorization filter name

1. Authentication filter name

• anon: Indicates that you can access resources without logging in
• user: Indicates that users must log in to access resources, and do not check when logging in ()
• authc: Indicates that login authentication is required to access resources, generally used for login interfaces

2. Authorization filter name

• perms: For example /public/**=perms[user:add:*]; multiple parameters can be written, and quotation marks must be added when there are multiple parameters, and the parameters must be separated by commas. For example /public/**=perms["user:add:*,user:modify:*"], when there are multiple parameters, each parameter must be passed before passing, which is equivalent to the isPermitedAll() method.
• roles: For example /admin/**=roles[admin]; more than one parameter can be written, and quotation marks must be added when there are more than one, and the parameters must be separated by commas. When there are multiple parameters, for example, /admin/**=roles["admin,guest"]each parameter is passed, which is equivalent to the hasAllRoles() method.

3. Authorization method

There are 4 main types:

• Programmatic: done with if/else code blocks.
• Annotation: It is completed by placing corresponding annotations on the executed method, and a corresponding exception will be thrown if there is no permission.
• View page: It is completed through corresponding tags in the view page (Beetl/JSP).
• URI-based interception: Determine access rights based on URI matching.

The following mainly introduces annotation and URI-based interception.

1. Programmatic (specific to data)

Scenario: Editing and auditing share the same resource. You can judge whether you have auditing authority in the resource, and then perform the corresponding operation.
Specific application example: Whether the user has the authority to operate on a certain item or type of data in the list

Subject subject = UserUtils.getSubject();
subject.isAuthenticated();            // 是否身份验证授权通过
subject.isPermitted(permission);      // 验证权限字符串
subject.isPermittedAll(permissions);  // 验证权限字符串全部通过
subject.hasRole(roleIdentifier);      // 验证是否有角色权限

2. Annotation (fine-grained)

Scenario: Permission filtering is performed on URL resources, buttons, and other operations. If the user skips the interface verification, accessing the URL address directly requires authorization verification.
For example: the user has the authority of user management (but does not specify which users are managed).
Specific application example: whether the current user has the authority to add users (whether it can request to add an interface)

Specify the following annotations on the Controller method:

• @RequiresPermissions (value={“sys:user:view”, “sys:user:edit”}, logical= Logical.OR): Indicates that the current Subject needs permission user:view or user:edit.
• @RequiresRoles(value={“admin”, “user”}, logical=Logical.AND): Indicates that the current Subject requires roles admin and user
• @RequiresAuthentication: Indicates that the current Subject has been authenticated through login;
• @RequiresUser: Indicates that the current Subject has been authenticated or logged in by remembering me.
• @RequiresGuest: Indicates that the current Subject has no identity verification or remembers that I have logged in, that is, it is a tourist identity.

3. URI-based interception (coarse-grained)

Scenario: When it is inconvenient to use programming, annotation, etc. to filter permissions, you can use URI to control permissions, or globally control the permissions of a URI address. For example:
users are only allowed to modify department A (users in departments B and C cannot be modified)
Specific application example: determine whether the current subject has permission to access certain pages

Format:
URI地址及通配符 = 过滤器名称（支持多个，用英文逗号分隔并加双引号）
The above permission filter definition configuration is based on the first match priority principle from top to bottom, and URIs that match successfully are given priority, and wildcards are supported.

3. Supplement: What are coarse-grained and fine-grained permissions?

• Coarse-grained: The management of resource types is called coarse-grained permission control, that is, it only controls menus, buttons, and methods.
• Fine-grained: The control of resource instances is called fine-grained rights management, that is, the rights controlled to the data level.