Recientemente, estaba trabajando en un proyecto de aplicación. Lo desarrollé solo en el fondo. Las funciones básicas de la verificación de inicio de sesión, registro y permiso no se incluyeron en la primera etapa de desarrollo en el orden de las tareas de desarrollo. Ahora se han completado algunas funciones relacionadas con el negocio, pero el portal de los usuarios aún no se ha implementado. Esto solo muestra que estaba demasiado ansioso cuando analicé por primera vez los requisitos y dejé atrás el portal de usuario más básico.
Ahora necesita agregar funciones de inicio de sesión y verificación de permiso del usuario basadas en el código existente.
Con respecto a la verificación de inicio de sesión y permiso, referirse a la experiencia anterior de desarrollo de iOS, el lado de la aplicación proporciona nombre de usuario y contraseña para intercambiar tokens, y se requiere un permiso de inicio de sesión para cada solicitud a través del token intercambiado.
Ahora, por otro lado, necesito considerar los siguientes problemas:
1. Cómo cumplir fácilmente con la implementación de estas funciones en el código de funciones existentes, para que el código existente no cambie mucho, y no habrá problemas para implementar la verificación de permisos en el futuro.
2. Cómo generar tokens basados en el nombre de usuario y la contraseña, y cómo distinguir la corrección del cliente que proporciona tokens en las funciones que requieren permisos
En primer lugar, enfrentar el primer problema, según la experiencia, la solución convencional son los filtros e interceptores. Si la verificación de inicio de sesión y permiso se coloca en el acuerdo de requisitos, siempre que las URL de las funciones posteriores tengan un cierto patrón, el uso de filtros o interceptores tendrá éxito. Pero ahora me enfrento a URL que no tienen diseño ni especificaciones en la etapa inicial, por lo que no quiero enfrentarme usando filtros o interceptores.
Además de las soluciones convencionales anteriores, Spring AOP se ha convertido en un arma para resolver este tipo de problema. Utiliza la programación de la cara enemana para proporcionar una pre-notación para todos los métodos que requieren verificación de permiso. Sin embargo, debido a que la URL, el nombre o el método de clase no es regular, pensé en una anotación personalizada y verifiqué los permisos para todos los métodos que agregan anotaciones personalizadas.
1. Dado que ya ha pensado en usar Spring AOP, el primer paso es habilitar AOP en el archivo de configuración de Spring
// Abrir AOP
<aop: aspectoj-autoproxy />
La configuración anterior se basa en verter paquetes JAR relacionados con Spring-AOP en el proyecto e introducir la URL de AOP en el encabezado del archivo de configuración.
2. Luego, definamos primero una anotación personalizada
@Target ({elementtype.method, elementtype.type}) @retención (retenciónPolicy.Runtime) public @Interface UserAccess {}3. No podemos apresurarnos a hacer funciones de verificación de permiso, porque nuestro token aún no ha generado una solución.
En orden de generación del token, se considera el inicio de sesión único, por lo que los tokens no se pueden solucionar todo el tiempo. De lo contrario, en cualquier momento, siempre que tenga tokens, al menos dos personas pueden usar la misma cuenta al mismo tiempo, lo que no está permitido en nuestro negocio en la actualidad. Al final, elegí el "nombre de usuario + contraseña + tiempo de inicio de sesión" para hacer el cifrado MD5 como un token (hay muchos métodos, como UUID al garantizar la singularidad y la mutabilidad). Genere tokens cuando el nombre de usuario y la contraseña se verifiquen con éxito, y guarde el token en forma de pares de valor clave de "Nombre de usuario: Token" y "Token: User" (también se puede guardar en la base de datos), y finalmente devolver el token al cliente.
El siguiente código es solo un simple ejemplo:
@Servicepublic class LoginService {/*** Store "User name: token" key-value pair */public static Map<String,String> tokenMap=new HashMap<String,String>();/*** Store "token:User" key-value pair */public static Map<String,User> loginUserMap=new HashMap<String,User>(); Public String Login (String Name, String Password) {System.out.println (nombre+"-----"+contraseña);/*** Compruebe si el inicio de sesión es exitoso* 1. Iniciar sesión con éxito* 1.1. Genere con éxito el token y actualización correspondiente * 1.2. Lanzar una excepción si falla*/String token = tokenmap.get (name); user user = null; if (token == null) {user = new user (); user.setName (name); user.setPassword (contraseña); system.out.println ("New userser.e user login ");} else {user = loginusermap.get (token); loginusermap.remove (token); system.out.println (" actualizar el usuario del usuario token ");} token = md5util.md5 (nombre+contraseña+nueva fecha (). token); system.out.println ("actualmente"+tokenmap.size ()+"usuarios"); para (usuario u: loginusermap.values ()) {system.out.println (u.getName ()+":"+u.getpassword ());} return token;}}4. Al mismo tiempo, nuestro cliente ha obtenido un token después de iniciar sesión. Mientras llevemos el token en todas las solicitudes que requieren permiso, podemos obtener con éxito la respuesta (sugerencia: para facilitar la codificación de la aplicación, el token puede llevarse a cabo en el encabezado de solicitudes, y el código existente no necesita ser cambios importantes, y no necesitamos preocuparnos por los problemas de token en el futuro). Acabo de encontrar un método para hacer un experimento:
@Controlador@requestmapping ("/login") clase pública logincontroller {@aUtowiredPrivate loginService loginservice; @UserAccess @requestMapping (valor = "/loginin", método = requestmethod.get) public @ResponseBody String String login (httpservletRequest request) {String name = request.getParameter ("name"); string contraseña = request.getParameter ("contraseña"); string token = loginservice.login (name, contraseña); regreso toKen;}Tenga en cuenta que la parte en negrita es personalizar la anotación. Es imposible tener tokens para los parámetros de solicitud de la función de inicio de sesión, por lo que no importa cuántas veces se verifique, no se puede pasar. Solo haz un ejemplo. @UserAccess Agregar solo funciona en la funcionalidad que requiere verificación de permiso
5. La anotación personalizada es ahora un buen punto de entrada
@Componente@AspectPublic Clase PermissionSeSpect {// Establezca la anotación personalizada como el punto de entrada @bebore ("@annotation (com.example.chap01.annotation.userAccess)") public void checkPermission (unión de unión de unión) lanza la excepción {system.println ("pre-notificación"); // obtenga parámetros de solicitud interptidos objeto [] argumentos [] argumentos [] unkePoint.getArgs (); httpservletRequest request = (httpservletRequest) args [0]; string token = request.getParameter ("token"); system.out.println ("token pre-notificación:"+token); user user user = loginservice.loginusermap.get (token); if (user == null) {system.out.println ("La verificación no se pasa!"); arroje una nueva excepción ("sin permiso");}}}En este punto, las funciones de verificación de inicio de sesión y permiso se completan todas.
Además, se adjunta el código fuente en GitHub personal: https://github.com/zw201913/applogin.git
Lo anterior se trata de este artículo, espero que sea útil para el aprendizaje de todos.