In the past two days, because I used ajax on the front end to initiate an asynchronous update request, I found that ajax would expose the interface address of the backend. Of course, this problem is inevitable, and the front end is plain text. Unfortunately, I asked various questions in Baidu, Google, and QQ groups. They all said that the problem can only be solved through security verification. As a novice, the first choice is of course session. There are token verification, shrio frameworks, etc. online. Friends who are interested can search for tutorials online to learn.
session is a cache mechanism for existing servers, which can verify whether the user has logged in. I wrote down what I learned so that novices can avoid bending paths and directly upload the code ~
First, the HttpServletRequest request request needs to be added to the SSM login interface parameters to obtain the session carried by the request.
Second, set the session in the login interface code, HttpSession session = request.getSession(true); //This sentence is to get session, true means that if there is no session, create a new session without filling in it.
session.setAttribute("logined","success"); //This sentence is to write a logo. You can also set the logged-in account in the session to prevent maliciously tampering with the information of another account when initiating a modification request.
Third, how to verify on the interface? It is also necessary to use the HttpServletRequest request parameter to obtain the session carried by the client initiating an http request. HttpSession session = request.getSession(); session.getAttribute("logined") to read whether there is a logined key. If there is no login, the requested content will not be given, and the information will be returned directly to remind the user to log in.
SSM project session scope problem
Description: After the user logs into the system successfully, puts the user's relevant information into a session domain for easy call, and is named xx.
When the user logs in to this system, he/she needs to modify his/her personal information. After the modification is completed, the user’s modified personal information on the front desk page is re-stamped into this session domain to overwrite the previous session. In this way, when the user logs in again or checks, the information after he/she changes it.
Analysis: When the user wants to modify his personal information after modifying his personal information (modifying personal information and modifying personal passwords are not on the same page), the old password entered will be prompted to be wrong, because there is no personal password when modifying personal information. That is, when the user modifies his own information and stuffs his information into the session, the personal password is encapsulated with an empty value, and the real password for the user's login cannot be obtained at this time.
Solution: If you want to smoothly modify your personal password after modifying your personal information, you must add a hidden domain of the user password to the page where you modify your personal information. In this way, the personal login password will be encapsulated into the object with the information modified by the user, and will be stuffed into the session domain. This way, the internal push in the session domain can be called when modifying the password, and the password will not be empty.
The above is all the content of this article. I hope it will be helpful to everyone's learning and I hope everyone will support Wulin.com more.