The difference between Session and Cookie
1. The concept of
Session Session is stored on the server side, similar to the Session structure to store user data. When the browser sends a request for the first time, the server automatically generates a Session and a Session ID to uniquely identify the Session, and It is sent to the browser in response. When the browser sends a request for the second time, it will put the Session ID in the previous server response in the request and send it to the server. The server extracts the Session ID from the request and compares it with all the saved Session IDs to find The Session corresponding to this user.
Under normal circumstances, the server will save the session for a certain period of time (30 minutes by default), and after the time limit, the session will be destroyed. Before the destruction, the programmer can temporarily store some user data in the form of Key and Value in this Session. Of course, there are also databases that use a database to serialize the Session and save it. The advantage of this is that there is no time limit, but the disadvantage is that as time increases, the database will expand rapidly, especially when the number of visits increases. The former method is generally adopted to reduce server pressure.
Second, the client implementation of Session (that is, the saving method of Session ID).
Generally, browsers provide two ways to save, and there is another way that programmers use html to hide the domain to customize the implementation:
[1] Using Cookie to save, this is the most common method. The realization of the "remember my login status" function in this article is officially based on this method. The server sends the Session ID to the browser by setting a cookie. If we do not set this expiration time, then the cookie will not be stored on the hard disk. When the browser is closed, the cookie disappears and the Session ID is lost. If we set this time to several days later, then this cookie will be saved in the client's hard disk, even if the browser is closed, this value will still exist, the next time we visit the corresponding website, it will also be sent to the server.
[2] The way to use URL additional information is like we often see aaa.jsp?JSESSIONID=* on JSP websites. This method is the same as the first method without setting the cookie expiration time.
[3] The third method is to add hidden fields in the page form. This method is actually the same as the second method, except that the former sends data through GET and the latter sends data through POST. But the latter is obviously more troublesome.
The difference between cookie and session:
The cookie data is stored on the client side, and the session data is stored on the server side.
Simply put, when you log in to a website, if the web server uses session, then all data is stored on the server. The client sends the sessionid of the current session every time it requests the server, and the server uses the current sessionid. Determine the corresponding user data flag to determine whether the user is logged in or has a certain authority. Because the data is stored on the server, you can't forge it, but if you can get the sessionid of a logged-in user, using a special browser to forge the user's request can also be successful. The sessionid is randomly assigned when the server and the client are connected. Generally speaking, there will be no repetition, but if there are a large number of concurrent requests, it is not without the possibility of repetition. I have encountered it once. After logging in to a certain website, I started to display my own information. After a period of time expired, when I refreshed it, the information of others was displayed.
If the browser uses cookies, then all the data is saved on the browser side. For example, after you log in, the server sets a cookie username (username), then when you request the server again, the browser will add the username together Sent to the server, these variables have a certain special mark. The server will interpret it as a cookie variable. So as long as you don't close the browser, the cookie variable is always valid, so you can guarantee that you won't be dropped for a long time. If you can intercept the cookie variable of a certain user, and then send a forged data packet, then the server still thinks you are legitimate. Therefore, the use of cookies is more likely to be attacked. If the effective time is set, then it will save the cookie on the client's hard disk. Next time you visit the website, the browser will first check whether there is a cookie, if there is, it will read the cookie, and then send it to server. If you save a forum cookie on your machine, the validity period is one year, if someone invades your machine, copy your cookie away, and put it under the directory of his browser, then it will be when he logs into the website Log in with your identity. So cookies can be forged. Of course, you need an idea when forging, copy the cookie file directly to the cookie directory, the browser does not recognize it, it has an index.dat file, which stores the creation time of the cookie file and whether it has been modified, so you must first have it The cookie file of this website, and to cheat the browser from the guarantee time, I have done experiments on the school’s vbb forum, copying other people’s cookies to log in, and using someone else’s name to post posts, there is no problem at all.
Session is a server-side storage space maintained by the application server. When a user connects to the server, the server generates a unique SessionID, and uses the SessionID as an identifier to access the server-side Session storage space. The SessionID data is saved to the client and saved with a Cookie. When the user submits the page, the SessionID will be submitted to the server to access the Session data. This process does not require developer intervention. So once the client disables cookies, the session will also become invalid.
The server can also pass the value of SessionID through URL rewriting, so it is not entirely dependent on cookies. If the client-side Cookie is disabled, the server can automatically save the Session value by rewriting the URL, and this process is transparent to the programmer.
You can try, even if you don't write cookies, you are using request.getCookies(); The length of the cookie array retrieved is also 1, and the name of this cookie is JSESSIONID, and there is a very long binary string that is the value of SessionID.
Three: The difference and connection between Session and Cookie:
Cookies are a kind of Session object. But there are differences. Cookies do not occupy server resources, but are stored in the client memory or a cookie text file; while "Session" will occupy server resources. Therefore, try not to use Session and use Cookies. But we generally think that cookies are unreliable, and sessions are reliable, but currently many famous sites also use cookies. Sometimes in order to solve the page processing after the cookie is disabled, the url rewriting technology is usually used, and a large number of useful methods in the session are called to obtain data from the session and put it into the page.
Application scenarios of Cookies and Session:
The security performance of Cookies has always been controversial. Although Cookies are stored on this machine, the full visibility of their information and the ease of local editing can often cause a lot of security problems. So whether or not Cookies should be used, and how they should be used, has a bottom line that needs to be given.
Let’s take a look at the sensitive data on the website.
Login verification information. Generally, the form of Session("Logon")=true or false is adopted.
Various personal information of the user, such as name, etc., under certain circumstances, needs to be stored in the Session.
Content information that needs to be transferred between pages, such as survey work needs to be divided into several steps. The information of each step is stored in the Session, and finally updated to the database in a unified manner.
Of course there will be many more. Here are some typical ones.
Suppose a person is so withdrawn that he does not want to touch Session, because he believes that if the user accidentally closes the browser, all the previously saved data will be lost. Therefore, out of good intentions, he decided to change these places where Session is used to store cookies. This is completely feasible, and the basic operation is exactly the same as using Session. So, the following is an analysis of the above three typical examples.
It is obvious that as long as an intentional illegal intruder knows what the session variable of the website is to verify the login information, then he can edit the Cookies in advance and put them in Go to the Cookies directory, so that you can successfully pass the verification. Is this scary?
Cookies are completely visible. Even if the programmer sets the lifetime of Cookies (for example, they are valid only during the validity period of the user's session), they are not safe. Assuming that the user forgets to close the browser or a malicious person stuns the user forcibly, the user's loss will be huge.
This is the same as the above point, it is easy for others to steal important private information. However, another problem is that the amount of information may be too large, which makes the file size of Cookies increase sharply. This is not what the user wants to see.
Obviously, Cookies are not such a good cookie. However, the existence of Cookies, of course, has its reasons. It gives programmers more space to develop their programming skills. Therefore, there is a bottom line for using Cookies. This bottom line generally follows the following principles.
Don't save private information.
Any important data, it is best to save the data in encrypted form (the simplest can be URLEncode, of course, you can also use a perfect reversible encryption method, unfortunately, it is best not to use md5 to encrypt).
Whether to save the login information or not, the user needs to choose by himself.
Do not use Cookies for data longer than 10K.
Don't use Cookies to play small games that surprise customers.
Fourth, the most typical applications of cookies are:
(1): Determine whether the user has logged in to the website, so that they can log in directly next time they log in. If we delete the cookie, we must fill in the relevant information about the login every time we log in.
(2): Another important application is the processing and design of classes in the "shopping cart". The user may choose different products on different pages of the same website within a period of time. This information can be written into the cookie, and the information can be extracted from the cookie when the final payment is made. Of course, there are security and performance issues that need to be considered. .