Session usage and scope of SSM project

In the past two days, I used Ajax to initiate asynchronous update requests on the front end. I found that Ajax would expose the interface address of the back end. Of course, this problem can not be avoided. The front end is plaintext. Poor, so I asked all kinds of queries and questions in Baidu, Google and QQ groups. They all said that they can only solve the problems through security verification. Of course, the first choice for novices is session. There are token verification and shrio framework on the Internet. Interested friends can search online for tutorials and learn.

Session is a caching mechanism of the existing server, which can verify whether the user has logged in. I write what I have learned, which can make novices take less detours and directly code~

First, an HttpServletRequest request request needs to be added to the login interface parameters of SSM to obtain the session carried by the request

Second, set the session with the code in the login interface. Httpsession = request getSession(true); // This sentence is to obtain a session. True means to create a new session if there is no one. You can leave it blank

session. setAttribute("logined","success"); // This sentence is to write an identity. You can also set the login account in the session to prevent malicious tampering with the data of another account when initiating a modification request.

Third, how to verify the interface? Similarly, the request with HttpServletRequest request parameter is required to obtain the session carried by the HTTP request initiated by the client. Httpsession session = request getSession(); session. Getattribute ("logged") reads whether there is a logged key. If there is no indication that the user has not logged in, the request content will not be given, and the information will be returned directly to remind the user to log in.

Session scope of SSM project

Description: after the user logs in to the system successfully, put the relevant information of the user into a session domain for easy calling, and name it XX,

When a user logs in to the system, he / she needs to modify his / her personal information. After the modification, the user's modified personal information on the foreground page is re inserted into the session field to overwrite the previous session, so that the user's modified information is when he / she logs in or views it again.

Analysis: when the user changes his personal information, he wants to change his personal login password (the modification of personal information and the modification of personal password are not on the same page). At this time, you will be prompted that the old password entered is wrong, because there is no personal password when modifying personal information, that is, when the user inserts his own information into the session after modifying, the personal password will be null, and the real password of the user's login will not be obtained.

Solution: if you want to successfully modify your personal password after modifying your personal information, you should add a hidden field of user password to the page of modifying your personal information. In this way, the personal login password will be encapsulated into the object along with the information modified by the user, and will be stuffed into the session domain. In this way, the push in session domain can be called when modifying the password, and the password will not be empty.

The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.