ShiroJwt

ShiroJwt

Adresse frontale : https://github.com/wang926454/VueStudy/tree/master/VueStudy08-JWT

Afficher les questions

1. #14 Les requêtes répétées généreront-elles plusieurs jetons ?
2. #19 Problème d'authentification unique inter-domaines
3. #29 Traitement simultané d'actualisation des jetons

Si vous avez des questions, veuillez scanner le code et rejoindre le groupe QQ pour communiquer : 779168604

Lié au projet

• JavaDoc : https://apidoc.gitee.com/dolyw/ShiroJwt
• Document d'interface : https://note.dolyw.com/shirojwt/ShiroJwt-Interface.html
• Répertoire du didacticiel : https://note.dolyw.com/shirojwt
• Passer au formulaire de base de données (MySQL) : https://note.dolyw.com/shirojwt/ShiroJwt02-MySQL.html
• Résolvez le problème selon lequel l'erreur 401 ne peut pas être renvoyée directement : https://note.dolyw.com/shirojwt/ShiroJwt03-401.html
• Implémentez la fonction Cache de Shiro (Redis) : https://note.dolyw.com/shirojwt/ShiroJwt04-Redis.html

Présentation du projet

1. API RESTful
2. Maven intègre Mybatis Generator (ingénierie inverse)
3. Shiro + Java-JWT implémente un mécanisme d'authentification sans état (Token)
4. Cryptage du mot de passe (en utilisant AES-128 + Base64)
5. Intégrer Redis (Jedis)
6. Réécrire le mécanisme de mise en cache Shiro (Redis)
7. Enregistrer les informations RefreshToken dans Redis (rendant JWT contrôlable)
8. Actualiser automatiquement AccessToken en fonction de RefreshToken

À propos de Shiro + Java-JWT pour implémenter un mécanisme d'authentification sans état (Token)

1. Tout d’abord, publiez le nom d’utilisateur et le mot de passe sur user/login pour vous connecter. En cas de succès, le AccessToken crypté sera renvoyé. En cas d’échec, une erreur 401 sera renvoyée directement (le compte ou le mot de passe est incorrect).
2. Apportez simplement cet AccessToken avec vous pour de futures visites.
3. Le processus d'authentification réécrit principalement le filtre d'entrée de Shiro JWTFilter ( BasicHttpAuthenticationFilter ) pour déterminer si l' en-tête de la demande contient le champ Autorisation .
4. Si oui, effectuez l'authentification et l'autorisation de connexion au jeton de Shiro (chaque demande d'accès utilisateur nécessitant une autorisation doit ajouter le champ Autorisation dans l'en-tête pour stocker le AccessToken ), sinon, utilisez l'accès direct en tant que visiteur (s'il existe un contrôle d'autorisation , l'accès des visiteurs sera intercepté)

Concernant AES-128 + Base64, lorsque les mots de passe en clair de deux utilisateurs sont identiques et cryptés, on constatera qu'il existe des mots de passe en texte chiffré avec la même structure dans la base de données.

La plupart d'entre eux résolvent ce problème sous la forme de MD5 + salt (détails de Baidu). J'utilise AES-128 + Base64 pour crypter le mot de passe sous forme de compte + mot de passe. Le compte étant unique, la même structure n'apparaîtra pas. .Le problème du mot de passe secret

À propos de l'intégration des classes d'outils Jedis avec SpringBoot

À l'origine, JedisUtil était directement injecté en tant que Bean . Chaque fois qu'il est utilisé, il peut être injecté directement @Autowired Cependant, après avoir réécrit le CustomCache de Shiro , JedisUtil n'a pas pu être injecté, il a donc été remplacé par une injection statique dans le JedisPool. pool de connexions La classe d'outils JedisUtil appelle toujours directement la méthode statique Pas besoin d'injection @Autowired .

À propos de l'enregistrement des informations RefreshToken dans Redis (ce qui rend JWT contrôlable)

1. Une fois l'authentification de connexion réussie, les informations AccessToken sont renvoyées ( l'horodatage actuel et le numéro de compte sont enregistrés dans AccessToken ).
2. En même temps, définissez un RefreshToken dans Redis avec le compte comme clé et la valeur comme horodatage actuel (heure de connexion)
3. Désormais, lors de l'authentification, l'AccessToken ne doit pas avoir expiré et le RefreshToken correspondant doit exister dans Redis , et l'horodatage RefreshToken doit être cohérent avec l'horodatage des informations AccessToken avant que l'authentification ne soit transmise. Cela peut permettre la contrôlabilité de JWT.
4. Si vous vous reconnectez et obtenez un nouveau AccessToken , l'ancien AccessToken ne peut pas être authentifié, car les informations d'horodatage RefreshToken stockées dans Redis ne seront cohérentes qu'avec l'horodatage porté dans les dernières informations AccessToken générées , de sorte que chaque utilisateur ne peut utiliser que le dernier AccessToken. attestation
5. Le RefreshToken de Redis peut également être utilisé pour déterminer si un utilisateur est en ligne. Si un Redis RefreshToken est supprimé, le AccessToken correspondant à ce RefreshToken ne pourra plus passer l'authentification. Cela équivaut à contrôler la connexion de l'utilisateur et à éliminer l'utilisateur. .

À propos de l'actualisation automatique d'AccessToken en fonction de RefreshToken

1. Le délai d'expiration d'AccessToken lui-même est de 5 minutes (configurable dans le fichier de configuration) et le délai d'expiration de RefreshToken est de 30 minutes (configurable dans le fichier de configuration)
2. Lorsque 5 minutes se sont écoulées après la connexion, le AccessToken actuel expirera. Si vous apportez à nouveau le AccessToken pour accéder à JWT, une exception TokenExpiredException sera levée, indiquant que le jeton a expiré.
3. Commencez à déterminer s'il faut actualiser le AccessToken . Redis demande si le RefreshToken de l'utilisateur actuel existe et si l'horodatage porté par ce RefreshToken est cohérent avec l'horodatage porté par le AccessToken expiré.
4. S'il existe et est cohérent, actualisez l'AccessToken, définissez le délai d'expiration sur 5 minutes (configurable dans le fichier de configuration), l'horodatage sur le dernier horodatage, et définissez également l'horodatage dans RefreshToken sur le dernier horodatage et actualisez l'expiration. temps à 30 à nouveau Expiration en minutes (configurable dans le fichier de configuration)
5. Enfin, l' AccessToken actualisé est stocké dans le champ Autorisation de l'en-tête de la réponse et renvoyé (le front-end l'obtient et le remplace, et utilise le nouvel AccessToken pour l'accès la prochaine fois).

architecture logicielle

1. Cadre de base SpringBoot + Mybatis
2. Plug-in PageHelper + plug-in Mapper universel
3. Mécanisme d'authentification sans état Shiro + Java-JWT
4. Cadre de mise en cache Redis (Jedis)

Tutoriel d'installation

1. Le mot de passe du compte de base de données est par défaut root. S'il est modifié, veuillez modifier vous-même le fichier de configuration application.yml.
2. Après décompression, exécutez le script srcmainresourcessqlMySQL.sql pour créer la base de données et la table
3. Redis doit installer le service Redis par lui-même et le mot de passe du port est celui par défaut
4. SpringBoot peut être démarré directement avec l'outil de test PostMan

Mode d'emploi

Utilisez Mybatis Generator (modèle visuel personnalisé pour générer rapidement du code de base : https://github.com/wang926454/ViewGenerator)

Configurez d'abord le fichier srcmainresourcesgeneratorgeneratorConfig.xml (la configuration par défaut se trouve sous le package reverse au niveau inférieur du package d'origine), et exécutez-le dans la fenêtre de ligne de commande du répertoire de niveau pom.xml ( c'est-à-dire sous le répertoire racine du projet) (le principe est que mvn est configuré) (IDEA peut être exécuté directement en double-cliquant dans la fenêtre Plugins de Maven)

mvn mybatis-generator:generate

Utilisation de PostMan (acquisition et utilisation de jetons)

先设置Content - Type为application / json 

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

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

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

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

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

Référence de construction

1. Merci à SmithCruise pour le tutoriel simple Shiro+JWT+Spring Boot Restful : https://www.jianshu.com/p/f37f8c295057
2. Merci à Wang Hongyu pour [Mise en route avec Shiro] (1) Utilisation de Redis comme gestionnaire de cache : https://blog.csdn.net/why15732625998/article/details/78729254
3. Sac de remerciement ? Springboot de Breeder (7) intègre Jedis pour implémenter le cache Redis : http://www.cnblogs.com/GodHeng/p/9301330.html.
4. Merci à W_Z_W_888 pour les trois méthodes d'injection de ressorts de variables statiques et leurs précautions : https://blog.csdn.net/W_Z_W_888/article/details/79979103
5. Merci à Vue2.0+ElementUI+PageHelper de Heavenly Wind and Cloud pour la mise en œuvre de la pagination des tables : https://blog.csdn.net/u012907049/article/details/70237457
6. Merci aux axios Vuejs de yaxx pour obtenir l'entête de réponse Http : https://segmentfault.com/a/1190000009125333
7. Merci à Twilight d'avoir résolu le problème causé par l'utilisation du jeton d'actualisation jwt : https://segmentfault.com/a/1190000013151506
8. Merci à l'intercepteur shiro de chuhx, qui renvoie des données json : https://blog.csdn.net/chuhx/article/details/51148877
9. Merci à yidao620c pour les règles de configuration de l'intercepteur intégrées de Shiro : https://github.com/yidao620c/SpringBootBucket/tree/master/springboot-jwt

Participer et contribuer

1. Forkez ce projet
2. Créer une nouvelle branche Feat_xxx
3. Soumettre le code
4. Nouvelle demande de tirage