4 métodos para la autenticación del proyecto Spring Boot

El artículo presenta cuatro formas de implementar la autenticación universal en Spring-boot, incluido AOP tradicional, interceptores, analizadores de parámetros y filtros, y proporciona el código de ejemplo correspondiente y, finalmente, resumió brevemente sus secuencia de ejecución.

Prólogo

Recientemente me he sentido abrumado por interminables demandas comerciales y no tengo tiempo para respirar. Finalmente conseguí un trabajo que me permitió salir de mi zona de confort de codificación. Resolverlo fue muy tortuoso. Una vez me hizo dudar de mi vida, pero la cosecha también fue excelente. No era obvio en términos de código, pero sentí que había borrado el velo que Java, Tomcat y Spring siempre habían bloqueado. mis ojos. Llevándolos a un nuevo nivel de comprensión. No he publicado durante mucho tiempo, así que elegí un aspecto para resumir, con la esperanza de aprender otras cosas durante el proceso de clasificación.

Debido al próspero ecosistema de Java, cada módulo a continuación tiene una gran cantidad de artículos dedicados a él. Así que elegí otro ángulo, partiendo de problemas prácticos, para conectar estos conocimientos dispersos, de modo que puedas verlos como un resumen. Para obtener la introducción detallada definitiva de cada módulo, puede leer los documentos oficiales o leer otros blogs en Internet. Los requisitos son muy simples y claros, y no difieren en absoluto de los glamorosos requisitos propuestos por los productos: agregue una función de verificación de lista blanca de claves de aplicación universal a nuestro marco web, con la esperanza de que su escalabilidad sea mejor.

Este marco web fue implementado por los pioneros del departamento basado en spring-boot. Está entre el negocio y el marco Spring. Realiza algunas funciones comunes que están sesgadas hacia el negocio, como la salida de registros. , interruptores de función y espera de análisis de parámetros comunes. Por lo general, es transparente para la empresa, pero recientemente estuve ocupado completando los requisitos y escribiendo el código, y ni siquiera me di cuenta de su existencia.

AOP tradicional

Para este requisito, lo primero que me viene a la mente es, por supuesto, la interfaz AOP proporcionada por Spring-boot. Solo necesita agregar un punto de corte antes del método del controlador. y luego realice el pointcut. Simplemente procéselo.

Implementación

Los pasos a utilizar son los siguientes:

El pseudocódigo de la clase de aspecto es el siguiente:

Agregar el @ Anotación en la lista blanca del método Controlador para implementar la función.

Extensión

En este ejemplo, las anotaciones se utilizan para declarar puntos de corte y he implementado parámetros de anotación para declarar la lista blanca que se verificará si es necesario agregar otras listas blancas más adelante. se verifica a través de UID, puede agregar métodos como uid() a esta anotación para implementar una verificación personalizada. Además, el AOP de Spring también admite métodos de declaración de punto de corte, como ejecución (método de ejecución), bean (método de ejecución de objetos Bean que coinciden con nombres específicos) y @Around (ejecutado durante la ejecución de la función de destino), @After (después de la ejecución del método). ), etc. Método de notificación. De esta manera, se implementó la función, pero el líder no está satisfecho =_=. La razón es que se ha usado demasiado y abusado de AOP en el proyecto. Bueno, sólo tenía que empezar.

Interceptor

Spring's Interceptor también es muy adecuado para implementar esta función. Como sugiere el nombre, el interceptor se utiliza para determinar si se ejecuta este método a través de algunos parámetros antes de que se ejecute la Acción en el Controlador. Para implementar un interceptor, puede implementar la interfaz HandlerInterceptor de Spring.

Implementación

Los pasos de implementación son los siguientes:

La clase AppkeyInterceptor es la siguiente:

Extensión

Para habilitar el interceptor: Para configurarlo explícitamente para que esté habilitado, aquí usamos WebMvcConfigurerAdapter para configurarlo. Cabe señalar que el MvcConfiguration que lo hereda debe estar en la ruta ComponentScan.

También tenga en cuenta que después de que el interceptor se ejecuta con éxito, el código de respuesta es 200, pero los datos de respuesta están vacíos.

Después de usar el interceptor para implementar la función, al líder finalmente se le ocurrió un gran truco: ya tenemos un parámetro de autenticación, la clave de aplicación se puede obtener del parámetro de autenticación y la presencia o ausencia del La lista blanca se puede utilizar como parámetro de autenticación. De esta manera, ¿por qué no verificar durante la autenticación? emmm... Vómitos con sangre.

Si está aprendiendo Spring Boot, le recomiendo un tutorial gratuito que se ha serializado durante muchos años y continúa actualizándose: /spring-boot-learning-2x/

ArgumentResolver

El analizador de parámetros es una herramienta proporcionada por Spring para analizar parámetros personalizados. Nuestra anotación @RequestParam de uso común tiene su sombra. Utilizándola, podemos combinar los parámetros en lo que queramos antes de ingresar a la Acción del controlador. Spring mantendrá una ResolverList Cuando llegue la solicitud, Spring encontrará que hay parámetros de tipo personalizados (tipos no básicos) y probará estos Resolver en secuencia hasta que un Resolver pueda analizar los parámetros requeridos. Para implementar una resolución de parámetros, debe implementar la interfaz HandlerMethodArgumentResolver.

Implementación

La clase AuthParamResolver implementada es la siguiente:

Extensión

Por supuesto, el uso del analizador de parámetros también requiere una configuración separada. También configuramos dentro de WebMvcConfigurerAdapter:

Después de que se completó la implementación esta vez, todavía estaba un poco preocupado, así que busqué en línea para ver si había otras formas de lograr esta función y descubrí que Filter también es común.

Filtro

El filtro no lo proporciona Spring. Está definido en la especificación de Servlet y es compatible con el contenedor de Servlet. Las solicitudes filtradas por Filtro no se enviarán al contenedor Spring. Su implementación también es relativamente simple: simplemente implemente la interfaz javax.servlet.Filter. Dado que no está en el contenedor Spring, Filter no puede obtener los recursos del contenedor Spring y solo puede usar ServletRequest y ServletResponse de Java nativo para obtener los parámetros de solicitud. Además, el método doFilter de FilterChain debe llamarse explícitamente en un filtro; de lo contrario, se considerará que la solicitud ha sido interceptada.

La implementación es similar:

Extensión

El filtro también necesita mostrar la configuración:

Resumen

Cada uno de los cuatro métodos de implementación tiene su escenarios adecuados. Entonces, ¿cuál es el orden de llamada entre ellos? El filtro lo implementa el servlet, por lo que, naturalmente, se llama primero. El interceptor que se llama posteriormente se intercepta y no es necesario procesarlo más tarde, luego el analizador de parámetros y, finalmente, el punto de corte del aspecto.