[Shiro] Cadena de permiso y contenido relacionado de autenticación y autorización

1. Cadena de permiso

1. Formato

Recurso:Permiso:Operación
(el formato común es:Módulo:Función:Operación）

Recursos: se refiere a los objetos, datos o servicios que necesitan ser protegidos en el sistema. Un recurso puede ser un término general o un objeto específico.
Permisos: Se refiere a las operaciones o funciones sobre los recursos , que se utilizan para limitar el acceso y uso de los recursos. El permiso puede ser un verbo o una palabra descriptiva. Necesidad de representar exactamente lo que hace o hace el permiso.
Operación: Se refiere a la ejecución de acciones específicas correspondientes a un determinado permiso , como CRUD.

Los comodines ( *) representan uno o más.

También se pueden usar comodines simples, por ejemplo sys:user:*, se recomienda omitir como sys:user(los asteriscos no se pueden usar para separar la parte frontal).
El ejemplo 1 coincidirásys:user correctamente con todas las cadenas de permisos que comienzan con o. El ejemplo 2 coincidirá correctamente con todas las cadenas de permisos que comienzan con osys:usersys:user:
syssyssys:

2. Ejemplos específicos

Módulo:Función:Operación
Ejemplo 1: sys:user:editDelegadoMódulo del sistema: Función de usuario: Operación de edición
Ejemplo 2: report:couponReceive:*RepresentanteMódulo de informes: función de cobro de cupones: todas las operaciones

3. Otros separadores

Usar "/" como separador
Una ruta jerárquica que muestra cómo se dividen los permisos entre los recursos.
Por ejemplo,posts/view/read
El uso de "." como delimitador
suele ser apropiado para sistemas con jerarquías de recursos o objetos bien definidas, lo que hace que los permisos se parezcan más a componentes jerárquicos o espacios de nombres.
Por ejemplo,posts.view.read

Duda: Las 3 formas anteriores ( :, /, .), ¿qué separador debería usarse en el desarrollo real?
Respuesta: Comprensión personal , puede usar cualquiera de los dos, principalmente en función de cómo se definió el sistema al principio, y puede usar el que desee.

2. Contenido relevante de la autenticación y autorización

1. La diferencia entre autoridad, URI y URL

Permission (permiso): Entre otros separadores, se usa como separador "/", que es muy similar al estilo de URL y URI, pero se usa principalmente como una cadena de permisos.
URI : identifica de forma única un recurso.En filterChainDefinitionMap , el URI puede ser la dirección de la solicitud de backend o la ruta del recurso estático。

Comodines de URI:
1. ?: Coincide con un carácter. 【Un carácter arbitrario】
2. *: Haga coincidir cero o más cadenas de caracteres. 【Ruta arbitraria】
3. **: Haga coincidir cero o más rutas en la ruta. 【Ruta arbitraria y subruta】

Aviso:

Lo que está escrito arriba es URI (identificador uniforme de recursos) , no URL (localizador uniforme de recursos) . Hay una diferencia entre los dos:
URL es un URI específico, que es un subconjunto de URI. No solo identifica recursos de manera única, sino también Proporciona información para localizar este recurso. URI es un concepto abstracto semántico, que puede ser absoluto o relativo, mientras que URL debe proporcionar suficiente información para localizar y es absoluto.

En pocas palabras:
URI : número de identificación (solo puede saber que existe esa persona, pero no sabe quién es)
URL : dirección de identificación + nombre (no solo sabe quién es esta persona, sino que también la encuentra)
como siempre que pueda representar de forma única el recurso Es URI, y el método de acceso de sus recursos se proporciona sobre la base de URI es URL.
La referencia anterior:
La diferencia y conexión entre URI y URL

En el desarrollo real, el permiso (permiso) y el URI se usan en combinación.

@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);
}

En el ejemplo anterior, configuramos el URI en /public/**la ruta para que sea accesible sin autenticación ( anon), configuramos el URI en la ruta
para requerir autenticación y permiso para acceder ( ), y configuramos el URI en todas las demás rutas para requerir autenticación. acceso ( )./admin/**adminauthc,roles[admin]
authc

2. Nombre del filtro de autenticación y autorización

1. Nombre del filtro de autenticación

anon: Indica que puede acceder a los recursos sin iniciar sesión

user: Indica que los usuarios deben iniciar sesión para acceder a los recursos, y no marcar al iniciar sesión ()

authc: indica que se requiere autenticación de inicio de sesión para acceder a los recursos, generalmente utilizados para las interfaces de inicio de sesión

2. Nombre del filtro de autorización

perms: Por ejemplo /public/**=perms[user:add:*], se pueden escribir múltiples parámetros, y se deben agregar comillas cuando hay múltiples parámetros, y los parámetros deben estar separados por comas. Por ejemplo, /public/**=perms["user:add:*,user:modify:*"]cuando hay múltiples parámetros, cada parámetro se debe pasar antes de pasar, lo cual es equivalente al método isPermitedAll().

roles: Por ejemplo /admin/**=roles[admin], se puede escribir más de un parámetro, y se deben poner comillas cuando hay más de uno, y los parámetros deben estar separados por comas, cuando hay varios parámetros, por ejemplo, se pasa cada parámetro, que /admin/**=roles["admin,guest"]es equivalente al método hasAllRoles().

3. Método de autorización

Hay 4 tipos principales:

Programático: hecho con bloques de código if/else.

Anotación: se completa colocando las anotaciones correspondientes en el método ejecutado, y se lanzará una excepción correspondiente si no hay permiso.

Ver página: Se completa a través de las etiquetas correspondientes en la página de vista (Beetl/JSP).

Intercepción basada en URI: determine los derechos de acceso en función de la coincidencia de URI.

A continuación, se presentan principalmente la anotación y la interceptación basada en URI.

1. Programático (específico de los datos)

Escenario: la edición y la auditoría comparten un recurso. Puede juzgar si tiene autoridad de auditoría en el recurso y luego realizar la operación correspondiente.
Ejemplo de aplicación específica: si el usuario tiene la autoridad para operar un determinado elemento o tipo de datos en la lista

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

2. Anotación (de grano fino)

Escenario: realice el filtrado de permisos en recursos de URL, botones y otras operaciones. Si el usuario omite la verificación de la interfaz, el acceso directo a la dirección URL también requiere verificación de autorización.
~~Por ejemplo: el usuario tiene la autoridad de administración de usuarios (pero no especifica qué usuarios se administran)~~
Ejemplo de aplicación específica: si el usuario actual tiene la autoridad para agregar usuarios (si puede solicitar agregar una interfaz)

Especifique las siguientes anotaciones en el método del controlador:

@RequiresPermissions (value={“sys:user:view”, “sys:user:edit”}, logical= Logical.OR): Indica que el Asunto actual necesita permiso usuario:ver o usuario:editar.

@RequiresRoles(value={“admin”, “user”}, logical=Logical.AND): Indica que el Asunto actual requiere roles de administrador y usuario

@RequiresAuthentication: Indica que el Sujeto actual ha sido autenticado a través del inicio de sesión;

@RequiresUser: Indica que el Sujeto actual se ha autenticado o ha iniciado sesión al recordarme.

@RequiresGuest: Indica que el Sujeto actual no tiene verificación de identidad o recuerda que he iniciado sesión, es decir, es una identidad de turista.

3. Intercepción basada en URI (granularidad gruesa)

Escenario: Cuando no es conveniente usar programación, anotación, etc. para filtrar permisos, puede usar URI para controlar permisos, o controlar globalmente los permisos de una dirección URI. Por ejemplo: los usuarios solo pueden modificar el departamento
~~A los departamentos B y C no se pueden modificar) Ejemplo de aplicación específica: determinar si el~~ sujeto
actual tiene permiso para acceder a ciertas páginas

Formato:
URI地址及通配符 = 过滤器名称（支持多个，用英文逗号分隔并加双引号）
la configuración de definición de filtro de permisos anterior se basa en el principio de prioridad de la primera coincidencia de arriba a abajo, y los URI que coinciden correctamente tienen prioridad y se admiten comodines.

3. Suplemento: ¿Qué son los permisos detallados y detallados?

Granularidad gruesa: la gestión de tipos de recursos se denomina control de permisos de granularidad gruesa, es decir, solo controla menús, botones y métodos.

Granularidad: El control de instancias de recursos se denomina gestión de derechos de granularidad fina, es decir, los derechos controlados a nivel de datos.