Cookie, session, sessionid, and jsessionid, cookiejsessionid

Cookie, session, sessionid, and jsessionid, cookiejsessionid

Cookie, session, sessionid, and jsessionid. To understand the relationship between them, let's look at an interesting scenario to help you understand it.

We all know that the bank's receiving counters Receive customer deposits/withdrawals every day. There are several solutions:

1. with the memory of the clerk at the counter: the clerk at the reception desk handles the deposit/withdrawal business for each customer. The clerk's memory alone should record the appearance of each customer, and quickly know the customer's current deposits and the number of accesses, the amount of each access is what. ---- This method indicates that the Protocol itself supports the status.

2. passbook: the clerk saves the deposit/withdrawal information of each customer on the passbook and keeps it with the customer. When the customer deposits/withdraws money, they only need to take out the passbook, the clerk can check the passbook to view the deposit/withdrawal information of the current customer. Of course, you will immediately think, What Should customers do to modify this information? We also have measures to stamp each deposit/withdrawal record. Counterfeit information is not stamped. However, if the customer needs to forge the seal, the seal can also be forged. ---- This method is maintained on the client.

3. bank Card: Send a bank card to each bank user. The bank card has a unique card number without any other information. When the customer deposits/withdraws money, they take out the bank card, the computer that the Bank enters the card number quickly displays the current user's deposit/withdrawal records. The security of this method will be greatly improved. It is difficult for a user to modify his/her deposit/withdrawal information only by attacking the bank's server. ---- This method is maintained on the server side.

Cookie and session generation process:

We all know that the HTTP protocol itself is stateless. Customers only need to simply send requests to the server to download some files. Each request sent from the client to the server is independent. For the current web application, HTTP is "stateless", so many applications have to spend a lot of energy to record user behavior. Just like the first case we introduced above, bank staff have to spend a lot of effort to remember the deposit/withdrawal records of every user.

Programmers quickly discovered that web interaction could be greatly enhanced if they could provide dynamic information generated on demand. On the one hand, programmers add forms, scripts, DOM and other client behaviors to HTML to increase the interaction between web applications and clients. On the other hand, the CGI specification appears on the server side to respond to the dynamic requests of the client. As the transmission carrier, the HTTP protocol adds features such as file upload and cookie. The cookie principle is the same as the method described above to use passbook to record users.

Through the previous example, we have found that storing information through cookies may cause some security risks, because all the information is written on the client, the customer may modify or clear the information. Therefore, the session method is used to save user behavior. The principle of this method is the same as that of the bank card method described earlier.

Specifically, the cookie mechanism adopts the client-side persistence scheme, while the session mechanism adopts the server-side persistence scheme. At the same time, we can also see that because the server-side persistence scheme also needs to save an identifier on the client, the session mechanism may need to use the cookie Mechanism to save the identifier, but in fact it has other options.

Cookie and session mechanisms and principles:

Cookie Mechanism. The orthodox cookie distribution is implemented by extending the HTTP protocol. The server prompts the browser to generate the corresponding cookie by adding a special line in the HTTP response header. However, pure client scripts such as JavaScript or VBScript can also generate cookies. Cookies are automatically sent to the server in the background by the browser according to certain principles. The browser checks all stored cookies. If the declared range of a cookie is greater than or equal to the location where the requested resource is located, the cookie is attached to the HTTP request header of the requested resource and sent to the server.

Cookie content mainly includes: name, value, expiration time, path and domain. The path and the domain form the scope of the cookie. If no expiration time is set, it indicates that the cookie's life cycle is the browser session period. When the browser window is closed, the cookie disappears. This cookie is called a session cookie. Session cookies are generally stored in the memory instead of on the hard disk. Of course, this behavior is not standardized. If the expiration time is set, the browser will save the cookie to the hard disk, close it, and open the browser again. These cookies are still valid until the preset expiration time is exceeded. Cookies stored on hard disks can be shared among different browser processes, such as two IE Windows. For Cookies stored in the memory, different browsers have different processing methods.

Session mechanism. The session mechanism is a server-side mechanism. The server uses a structure similar to a hash (or a hash) to save information. When the program needs to create a session for a client request, the server first checks whether the client request contains a session id, which is called the session id, if it already exists, it indicates that a session has been created for this client. Then, the server retrieves and uses this session according to the session id (a new session will be created if it cannot be retrieved ), if the client request does not contain the session id, the client creates a session and generates a session id associated with the session. The session id value should be unique, the session id is returned to the client for saving in this response.

The cookie can be used to save the session id. In this way, the browser can automatically display the id to the server according to the Rules during the interaction. Generally, the cookie name is similar to SEEESIONID. However, if a cookie can be artificially disabled, there must be other mechanisms so that the session id can still be passed back to the server when the cookie is disabled. A frequently used technology called URL rewriting is to directly append the session id to the end of the URL path. Another technique is form hidden fields. The server automatically modifies the form and adds a hidden field so that the session id can be passed back to the server when the form is submitted.

Jsessionid?

Jsessionid is tomcat's name for sessionid, which is actually sessionid. It may not be called jsessionid in other containers.