Récemment, je travaillais sur un projet d'application. Je l'ai développé seul en arrière-plan. Les fonctions de base de la connexion, de l'enregistrement et de la vérification de l'autorisation n'ont pas été incluses dans la première étape du développement dans l'ordre des tâches de développement. Maintenant, certaines fonctions liées aux entreprises sont remplies, mais le portail utilisateur n'a pas encore été implémenté. Cela montre seulement que j'étais trop anxieux lorsque j'ai analysé les exigences pour la première fois et mené le portail utilisateur le plus élémentaire derrière.
Vous devez maintenant ajouter des fonctions de connexion et de vérification de l'autorisation de l'utilisateur en fonction du code existant.
En ce qui concerne la vérification de connexion et d'autorisation, se référant à l'expérience de développement iOS précédent, le côté de l'application fournit le nom d'utilisateur et le mot de passe pour échanger des jetons, et l'autorisation de connexion est requise pour chaque demande via le jeton échangé.
Maintenant, en revanche, je dois considérer les problèmes suivants:
1. Comment respecter facilement la mise en œuvre de ces fonctions dans le code des fonctions existantes, afin que le code existant ne soit pas beaucoup modifié et qu'il n'y aura pas de tracas pour implémenter la vérification de l'autorisation à l'avenir.
2. Comment générer des jetons en fonction du nom d'utilisateur et du mot de passe, et comment distinguer l'exactitude de la fourniture de jetons de client dans des fonctions qui nécessitent des autorisations
Tout d'abord, face au premier problème, selon l'expérience, la solution conventionnelle est les filtres et les intercepteurs. Si la connexion et la vérification de l'autorisation sont placées dans la disposition des exigences, tant que les URL des fonctions ultérieures reçoivent un certain modèle, l'utilisation de filtres ou d'intercepteurs réussira. Mais maintenant, je fais face à des URL qui n'ont pas de conception ou de spécifications au début, donc je ne veux pas faire face à des filtres ou des intercepteurs.
En plus des solutions conventionnelles ci-dessus, Spring AOP est devenu une arme pour résoudre ce type de problème. Il utilise la programmation face à la température pour fournir une pré-notation pour toutes les méthodes qui nécessitent une vérification de l'autorisation. Cependant, parce que l'URL, le nom de classe ou la méthode n'est pas régulier, j'ai pensé à une annotation personnalisée et à vérifier les autorisations pour toutes les méthodes qui ajoutent des annotations personnalisées.
1. Puisque vous avez déjà pensé à utiliser Spring AOP, la première étape consiste à activer AOP dans le fichier de configuration Spring
// Ouvrir AOP
<aop: aspectj-autoproxy />
La configuration ci-dessus est basée sur les packages JAR liés à Spring-AOP dans le projet et l'introduction de l'URL d'AOP dans l'en-tête du fichier de configuration.
2. Ensuite, définissons d'abord une annotation personnalisée
@Target ({elementType.Method, elementType.Type}) @ Rétention (RetentionPolicy.Runtime) public @Interface UserAccess {}3. Nous ne pouvons pas nous précipiter pour effectuer des fonctions de vérification d'autorisation, car notre jeton n'a pas encore généré de solution.
Dans l'ordre de la génération de jetons, la connexion unique est prise en compte, donc les jetons ne peuvent pas être réparés tout le temps. Sinon, à tout moment, tant que vous avez des jetons, au moins deux personnes peuvent utiliser le même compte en même temps, ce qui n'est pas autorisé dans notre entreprise à l'heure actuelle. En fin de compte, j'ai choisi "nom d'utilisateur + mot de passe + temps de connexion" pour faire le cryptage MD5 en tant que jeton (il existe de nombreuses méthodes, telles que l'UUID lors de la garantie de l'unicité et de la mutabilité). Générez des jetons lorsque le nom d'utilisateur et le mot de passe sont vérifiés avec succès, et enregistrez le jeton sous la forme de paires de valeurs clés de "nom d'utilisateur: jeton" et "token: utilisateur" (peut également être enregistré dans la base de données), et enfin renvoyer le jeton au client.
Le code suivant n'est qu'un exemple simple:
@ServicePublic Class LoginService {/ *** Store "Nom d'utilisateur: Token" Key-Value Pair * / Public Static Map <String, String> tokenMap = new Hashmap <String, String> (); / *** Store "Token: User" Key-Value pair * / public static map <string, utilisateur> LoginUserap = new Hashmap <string, user>;); Public String Login (nom de chaîne, mot de passe de chaîne) {System.out.println (nom + "-----" + mot de passe); / *** Vérifiez si la connexion est réussie * 1. Connexion avec succès * 1.1. Générez avec succès le jeton et mise à jour correspondant * 1.2. Lance une exception s'il échoue * / string token = tokenmap.get (name); utilisateur user = null; if (token == null) {user = new user (); user.setName (name); user.setpassword (mot de passe); system.out.println ("new user user Login ");} else {user = LoginUserMap.get (Token); LoginUserMap.Remove (Token); System.out.println (" Update User Login Token ");} token = md5util.md5 (name + mot de passe + new Date (). GetTime (); newinUsermap.put (token, user); tokenmP.put (newinusermap.put (token, user); tokenm token); System.out.println ("actuellement" + tokenmap.size () + "utilisateurs"); pour (utilisateur u: loginusermap.values ()) {System.out.println (u.getName () + ":" + u.getPassword ());} return token;}}}4. En même temps, notre client a obtenu un jeton après s'être connecté. Tant que nous portons le jeton dans toutes les demandes qui nécessitent une autorisation, nous pouvons obtenir avec succès la réponse (suggestion: pour faciliter le codage de l'application, le jeton peut être transporté dans les problèmes de demande, et le code existant n'a pas besoin d'être des changements majeurs, et nous n'avons pas besoin de prendre des problèmes sur le token dans le futur). Je viens de trouver une méthode pour faire une expérience:
@ Contrôleur @ requestmapping ("/ login") public class LoginController {@AutowiredPrivate LoginService LoginService; @ UserAccess @ requestmapping (value = "/ loginin", méthode = requestMethod.get) public @ResponseBody String Login (httpServLetRequest request) {String name = request.getParameter ("name"); String Password = request.getParAmter ("mot de passe"); String token = LoginService.Login (nom, mot de passe); return toKen;}}Notez que la partie audacieuse consiste à personnaliser l'annotation. Il est impossible d'avoir des jetons pour les paramètres de demande de la fonction de connexion, donc peu importe combien de fois il est vérifié, il ne peut pas être passé. Faites juste un exemple. @UserAccess Ajouter ne fonctionne que sur la fonctionnalité qui nécessite une vérification de l'autorisation
5. L'annotation personnalisée est maintenant un bon point d'entrée
@ Composant @ AspectPublic Class PermissionAspect {// Définissez l'annotation personnalisée comme point d'entrée @Before ("@ annotation (com.example.chap01.annotation.userAccess)") public Void CheckPermission (joinpoint) lance une exception interceptée {System.out.println ("pré-Notification"); // obtenir l'interception de la demande de paramètres de demande de paramètres de la demande de demande de paramètres de la demande de demande de demande de demande de paramètres de la demande de demande de paramètres de la demande de demande de paramètres de la demande de demande de paramètres de la demande de la demande de la demande de demande de paramètres de la demande de la demande d'interception paramètres de la demande [] de la demande interceptée paramètres de la demande de demande de paramètres de la demande de la demande de demande de paramètres de paramètres de paramètres = interceptée joinpoint.getArgs (); httpServLetRequest request = (httpServletRequest) args [0]; String token = request.getParameter ("token"); System.out.println ("token pré-notification:" + token); utilisateur; user = LoginService.logInUserMap.get (Token); if (user == null) {System.out.println ("Vérification n'est pas passé!"); Jetez une nouvelle exception ("aucune autorisation");}}}}À ce stade, les fonctions de connexion et de vérification d'autorisation sont toutes terminées.
De plus, le code source sur le github personnel est joint: https://github.com/zw201913/applogin.git
Ce qui précède concerne cet article, j'espère qu'il sera utile à l'apprentissage de tout le monde.