ShiroJwt

ShiroJwt

Dirección de interfaz de usuario: https://github.com/wang926454/VueStudy/tree/master/VueStudy08-JWT

Ver preguntas

1. #14 ¿Las solicitudes repetidas generarán múltiples tokens?
2. #19 Problema de sso entre dominios
3. #29 Procesamiento simultáneo de actualización de tokens

Si tienes alguna duda, escanea el código y únete al grupo QQ para comunicarte: 779168604

Relacionado con el proyecto

• JavaDoc: https://apidoc.gitee.com/dolyw/ShiroJwt
• Documento de interfaz: https://note.dolyw.com/shirojwt/ShiroJwt-Interface.html
• Directorio de tutoriales: https://note.dolyw.com/shirojwt
• Cambiar al formulario de base de datos (MySQL): https://note.dolyw.com/shirojwt/ShiroJwt02-MySQL.html
• Resuelva el problema de que el error 401 no se puede devolver directamente: https://note.dolyw.com/shirojwt/ShiroJwt03-401.html
• Implemente la función de caché de Shiro (Redis): https://note.dolyw.com/shirojwt/ShiroJwt04-Redis.html

Introducción del proyecto

1. API REST
2. Maven integra Mybatis Generator (ingeniería inversa)
3. Shiro + Java-JWT implementa un mecanismo de autenticación sin estado (Token)
4. Cifrado de contraseña (usando AES-128 + Base64)
5. Integrar Redis (Jedis)
6. Reescribir el mecanismo de almacenamiento en caché de Shiro (Redis)
7. Guarde la información de RefreshToken en Redis (haciendo que JWT sea controlable)
8. Actualizar automáticamente AccessToken según RefreshToken

Acerca de Shiro + Java-JWT para implementar un mecanismo de autenticación sin estado (Token)

1. Primero, publique el nombre de usuario y la contraseña en usuario/inicio de sesión para iniciar sesión. Si tiene éxito, se devolverá el AccessToken cifrado. Si falla, se devolverá un error 401 directamente (la cuenta o la contraseña son incorrectas).
2. Simplemente traiga este AccessToken para futuras visitas.
3. El proceso de autenticación principalmente reescribe el filtro de entrada JWTFilter ( BasicHttpAuthenticationFilter ) de Shiro para determinar si el encabezado de la solicitud contiene el campo Autorización .
4. En caso afirmativo, realice la autenticación y autorización de inicio de sesión del token de Shiro (cada solicitud de acceso de usuario que requiera permiso debe agregar el campo Autorización en el encabezado para almacenar el AccessToken ); de lo contrario, use el acceso directo como visitante (si hay control de permisos). , el acceso de los visitantes será interceptado)

Con respecto a AES-128 + Base64, cuando las contraseñas en texto plano de dos usuarios son iguales y están cifradas, se encontrará que hay contraseñas en texto cifrado con la misma estructura en la base de datos.

La mayoría de ellos resuelven este problema en forma de MD5 + salt (detalles de Baidu). Yo uso AES-128 + Base64 para cifrar la contraseña en forma de cuenta + contraseña. Debido a que la cuenta es única, no aparecerá la misma estructura. El problema de la contraseña secreta.

Acerca de la integración de clases de herramientas Jedis con SpringBoot

Originalmente, JedisUtil se inyectaba directamente como Bean . Cada vez que se usaba, se podía inyectar directamente @Autowired . Sin embargo, después de reescribir el CustomCache de Shiro , JedisUtil no se podía inyectar, por lo que se cambió a inyección estática en JedisPool. grupo de conexiones La clase de herramienta JedisUtil todavía llama directamente al método estático. No es necesario inyectar @Autowired

Acerca de guardar información de RefreshToken en Redis (hacer que JWT sea controlable)

1. Después de pasar la autenticación de inicio de sesión, se devuelve la información de AccessToken ( la marca de tiempo actual y el número de cuenta se guardan en AccessToken )
2. Al mismo tiempo, configure un RefreshToken en Redis con la cuenta como clave y el valor como marca de tiempo actual (hora de inicio de sesión)
3. Ahora, durante la autenticación, el AccessToken no debe haber caducado y el RefreshToken correspondiente debe existir en Redis , y la marca de tiempo del RefreshToken debe ser coherente con la marca de tiempo en la información de AccessToken antes de que se pase la autenticación. Esto puede lograr la controlabilidad de JWT.
4. Si inicia sesión nuevamente y obtiene un nuevo AccessToken , el antiguo AccessToken no se puede autenticar, porque la información de la marca de tiempo del RefreshToken almacenada en Redis solo será consistente con la marca de tiempo contenida en la última información del AccessToken generada , por lo que cada usuario solo puede usar el último AccessToken. proceso de dar un título
5. El RefreshToken de Redis también se puede utilizar para determinar si un usuario está en línea. Si se elimina un Redis RefreshToken , el AccessToken correspondiente a este RefreshToken ya no podrá pasar la autenticación. Esto equivale a controlar el inicio de sesión del usuario y eliminarlo. .

Acerca de la actualización automática de AccessToken según RefreshToken

1. El tiempo de vencimiento de AccessToken en sí es de 5 minutos (configurable en el archivo de configuración) y el tiempo de vencimiento de RefreshToken es de 30 minutos (configurable en el archivo de configuración)
2. Cuando hayan pasado 5 minutos después de iniciar sesión, el AccessToken actual caducará. Si vuelve a traer el AccessToken para acceder a JWT, se generará una excepción TokenExpiredException , lo que indica que el Token ha caducado.
3. Comience a determinar si actualizar AccessToken . Redis consulta si existe el RefreshToken del usuario actual y si la marca de tiempo que lleva este RefreshToken es coherente con la marca de tiempo que lleva el AccessToken caducado.
4. Si existe y es consistente, actualice AccessToken, establezca el tiempo de vencimiento en 5 minutos (configurable en el archivo de configuración), la marca de tiempo en la última marca de tiempo y también configure la marca de tiempo en RefreshToken en la última marca de tiempo y actualice la fecha de vencimiento. tiempo a 30 nuevamente. Caducidad en minutos (configurable en el archivo de configuración).
5. Finalmente, el AccessToken actualizado se almacena en el campo Autorización en el encabezado de la respuesta y se devuelve (la interfaz lo obtiene y lo reemplaza, y usa el nuevo AccessToken para acceder la próxima vez).

arquitectura de software

1. Marco central SpringBoot + Mybatis
2. Complemento PageHelper + complemento Mapper universal
3. Mecanismo de autenticación sin estado Shiro + Java-JWT
4. Marco de almacenamiento en caché de Redis (Jedis)

Tutorial de instalación

1. La contraseña de la cuenta de la base de datos tiene como valor predeterminado root. Si se modifica, modifique el archivo de configuración application.yml usted mismo.
2. Después de la descompresión, ejecute el script srcmainresourcessqlMySQL.sql para crear la base de datos y la tabla.
3. Redis necesita instalar el servicio Redis por sí mismo y la contraseña del puerto es la predeterminada
4. SpringBoot se puede iniciar directamente con la herramienta de prueba PostMan

Instrucciones de uso

Utilice Mybatis Generator (plantilla visual personalizada para generar rápidamente código básico: https://github.com/wang926454/ViewGenerator)

Primero configure el archivo srcmainresourcesgeneratorgeneratorConfig.xml (la configuración predeterminada está en el paquete inverso en el nivel inferior del paquete original) y ejecútelo en la ventana de línea de comando del directorio de nivel pom.xml ( es decir, en el directorio raíz del proyecto) (La premisa es que mvn está configurado) (IDEA se puede ejecutar directamente haciendo doble clic en los complementos de la ventana de Maven)

mvn mybatis-generator:generate

Uso de PostMan (adquisición y uso de tokens)

先设置Content - Type为application / json 

然后填写请求参数帐号密码信息

进行请求访问，请求访问成功

点击查看Header信息的Authorization属性即是Token字段

访问需要权限的请求将Token字段放在Header信息的Authorization属性访问即可

 Token的自动刷新也是在Token失效时返回新的Token在Header信息的Authorization属性

Referencia de construcción

1. Gracias a SmithCruise por el sencillo tutorial Shiro+JWT+Spring Boot Restful: https://www.jianshu.com/p/f37f8c295057
2. Gracias a Wang Hongyu por [Comenzar con Shiro] (1) Usar Redis como administrador de caché: https://blog.csdn.net/why15732625998/article/details/78729254
3. ¿Gracias bolso? Springboot de Breeder (7) integra jedis para implementar el caché de redis: http://www.cnblogs.com/GodHeng/p/9301330.html
4. Gracias a W_Z_W_888 por los tres métodos de inyección de variables estáticas por resorte y sus precauciones: https://blog.csdn.net/W_Z_W_888/article/details/79979103
5. Gracias a Vue2.0+ElementUI+PageHelper de Heavenly Wind and Cloud por implementar la paginación de tablas: https://blog.csdn.net/u012907049/article/details/70237457
6. Gracias a los axios Vuejs de yaxx para obtener el encabezado de respuesta Http: https://segmentfault.com/a/1190000009125333
7. Gracias a Twilight por resolver el problema causado por el uso del token de actualización jwt: https://segmentfault.com/a/1190000013151506
8. Gracias al interceptor shiro de chuhx, que devuelve datos json: https://blog.csdn.net/chuhx/article/details/51148877
9. Gracias a yidao620c por las reglas de configuración del interceptor integrado de Shiro: https://github.com/yidao620c/SpringBootBucket/tree/master/springboot-jwt

Participa y aporta

1. Bifurca este proyecto
2. Crea una nueva rama Feat_xxx
3. Enviar código
4. Nueva solicitud de extracción