En los últimos dos días, debido a que utilicé AJAX en la parte delantera para iniciar una solicitud de actualización asíncrona, descubrí que AJAX expondría la dirección de interfaz del backend. Por supuesto, este problema es inevitable, y la parte delantera es texto sin formato. Desafortunadamente, hice varias preguntas en los grupos de Baidu, Google y QQ. Todos dijeron que el problema solo se puede resolver a través de la verificación de seguridad. Como novato, la primera opción es, por supuesto, la sesión. Hay verificación de tokens, marcos shrio, etc. en línea. Los amigos interesados pueden buscar tutoriales en línea para aprender.
La sesión es un mecanismo de caché para los servidores existentes, que puede verificar si el usuario ha iniciado sesión. Escribí lo que aprendí para que los novatos puedan evitar la flexión y cargar directamente el código ~
Primero, la solicitud HttpServletRequest request debe agregarse a los parámetros de la interfaz de inicio de sesión SSM para obtener la sesión realizada por la solicitud.
En segundo lugar, establezca la sesión en el código de interfaz de inicio de sesión, HttpSession session = request.getSession(true); // Esta oración es obtener una sesión, verdadero significa que si no hay sesión, cree una nueva sesión sin completarla.
session.setAttribute("logined","success"); // Esta oración es escribir un logotipo. También puede establecer la cuenta iniciada en la sesión para evitar manipular maliciosamente la información de otra cuenta al iniciar una solicitud de modificación.
Tercero, ¿cómo verificar en la interfaz? También es necesario utilizar el parámetro de solicitud HTTPServletRequest para obtener la sesión realizada por el cliente que inicia una solicitud HTTP. HttpSession session = request.getSession(); session.getAttribute("logined") para leer si hay una clave logada. Si no hay inicio de sesión, el contenido solicitado no se dará y la información se devolverá directamente para recordarle al usuario que inicie sesión.
Problema de alcance de la sesión del proyecto SSM
Descripción: después de que el usuario inicie sesión en el sistema con éxito, coloca la información relevante del usuario en un dominio de sesión para una llamada fácil, y se llama xx.
Cuando el usuario inicia sesión en este sistema, él/ella necesita modificar su información personal. Una vez completada la modificación, la información personal modificada del usuario en la página de recepción se vuelve a sellar en este dominio de sesión para sobrescribir la sesión anterior. De esta manera, cuando el usuario inicia sesión nuevamente o verifica, la información después de él/ella la cambia.
Análisis: Cuando el usuario desea modificar su información personal después de modificar su información personal (modificar información personal y modificar las contraseñas personales no están en la misma página), se pedirá que la contraseña anterior ingresada sea incorrecta, porque no hay contraseña personal al modificar información personal. Es decir, cuando el usuario modifica su propia información y llena su información en la sesión, la contraseña personal está encapsulada con un valor vacío, y la contraseña real para el inicio de sesión del usuario no se puede obtener en este momento.
Solución: si desea modificar sin problemas su contraseña personal después de modificar su información personal, debe agregar un dominio oculto de la contraseña de usuario a la página donde modifica su información personal. De esta manera, la contraseña de inicio de sesión personal se encapsulará en el objeto con la información modificada por el usuario y se meterá en el dominio de la sesión. De esta manera, se puede llamar al dominio interno en el dominio de la sesión al modificar la contraseña, y la contraseña no estará vacía.
Lo anterior es todo el contenido de este artículo. Espero que sea útil para el aprendizaje de todos y espero que todos apoyen más a Wulin.com.