Cookies, session, SessionID and Jsessionid

Cookies, sessions, SessionID and Jsessionid, to understand the relationship between them, let's look at an interesting scene to help you understand.

We all know the bank, the bank's reception desk to receive customer deposits every day / Withdrawals business, there can be several scenarios:

1. With the memory of the counter clerk: from the counter clerk to each customer for the deposit / withdrawal business, the staff's memory, to remember the appearance of each customer, and quickly know the customer's current deposit and access to the number of times, the amount of each access. ---- This way indicates that the protocol itself supports States.

2. How to use the Passbook: The clerk puts each customer's deposit/the withdrawal information is stored in the passbook and then handed over to the customer for safekeeping, when the customer deposits/when withdrawing money, just take out the passbook and the clerk will check the Passbook for the current customer's deposit/withdrawal information at a glance. Of course, you will soon think, how do customers change this information? We also have measures for each deposit/The withdrawal record is stamped on the back. No stamp is counterfeit information. But if the customer isIt is true to forge, and of course the seal can be forged. ---- This way is to keep the state on the client.

3. How to use a bank card: send a bank card to each bank user, there is a unique card number on the bank card, no other information, when the customer comes to deposit / withdrawals , take out the bank card, the bank to enter the card number of the computer, will soon show the current user's save / withdrawals record. The security of this approach will be greatly improved. Users want to have their hands and feet breached the bank's server to modify their own storage/ withdrawal information, It's going to be a lot harder.   ----  This is the server-side hold state.

cookie with session Generation process:

we all know that. HTTP The protocol itself is stateless, and the client simply sends a request to the server to download some files, and each request sent to the server is independent. For the current Web application, the "stateless" HTTP, causing many applications to spend a lot of effort to record the user's behavior. As we described in the first case, the bank clerk spends a lot of effort to memorize each user's deposit / withdrawal record.

programmers quickly discovered that if they were able to provide some dynamic information generated on demand, they would makeWebgreatly enhanced interactive capabilities. Programmers on the one handHTMLadd forms, scripts,DOMsuch as client behavior, to increaseWebthe interaction of the application with the client. On the other hand, on the server side there areCGIspecification in response to a client's dynamic request, as a transmission carrierHTTPthe protocol adds file uploads,Cookiesand other characteristics. ThatCookiesthe same principle as the one we described above using Passbook recording users should be the same way.

through the previous examples we have found that through Cookies the way the information is stored, there may be some security implications because all of the information is written on the client and the customer may modify or clear the information. So the way that the session is used to save user behavior is the same as the way the bank card was introduced earlier.

In particular, the cookie mechanism uses a scheme that maintains state on the client, while the session mechanism uses a scenario that maintains state on the server side. At the same time, we also see that because of the server-side hold state of the scheme in the client also need to save an identity, so the session mechanism may need to use the cookie mechanism to achieve the purpose of preserving the identity, But in fact it has other options.

The mechanism and principle of the cookie and session:

Cookiesmechanism. The OrthodoxCookiesdistribution is done by extendingHTTPprotocol to implement, the server passes theHTTPA special line in the response header to prompt the browser to follow the instructions to generate the correspondingCookies. However, purely client-side scripts such asJavaScriptorVBScriptyou can also generateCookies. andCookiesis automatically sent to the server in the background by the browser in accordance with certain principles. The browser checks all storedCookies, if aCookiesWhen the declared scope is greater than or equal to the location of the resource being requested, theCookiesattached to the request resourceHTTPthe request header is sent to the server.

CookiesThe main contents include: Name, value, expiration time, path and domain. The path is formed with the domainCookiesrange of functions. If you do not set an expiration time, this indicatesCookiesduring the lifetime of the browser session, close the browser window,Cookieswill disappear. This is the lifetime of the browser sessionCookiesis called a sessionCookies. SessionCookiesgenerally not stored on the hard disk but in memory, of course, this behavior is not regulated. If the expiration time is set, the browser willCookiessave to the hard disk, close and open the browser again, theseCookiesremains valid until the set expiration time is exceeded. Stored on the hard diskCookiescan be shared between different browser processes, such as twoIEwindow. And for those stored in memory,Cookies, different browsers have different ways of handling.

Sessionmechanism. SessionA mechanism is a server-side mechanism that uses a hash-like structure (or perhaps a hash table) to hold information.  when a program needs to create one for a client's requestSession, the server first checks to see if the client's request contains aSessionIdentification--calledSessionID, if included, indicates that the client has previously created thisSession, the server will followSession IDput thisSessionretrieved using (not retrieved, a new one) if the client request does not containSession ID, the client creates aSessionand generate one with thisSessionassociated withSession ID,Session IDThe value should be a string that is neither repetitive nor easy to be found to mimic the pattern of thisSession IDwill be returned to the client in this response to be saved.

Save thisSession IDthe way you can useCookies, so that in the interactive process the browser can automatically follow the rules to play this identity to the server. Generally thisCookiesthe names are all similar toSeeesionid. ButCookiescan be artificially banned, there must be other mechanisms toCookieswhen banned, it is still possible toSession IDpassed back to the server. a technique that is often used is calledURLrewrite, is to putSession IDdirectly attached toURLthe back of the path. There is also a technique called form-hidden fields. Is that the server automatically modifies the form and adds a hidden field so that when the form is submitted it can beSession IDpassed back to the server.

Jsessionid?

Jsessionid just Tomcat the right SessionID the term, in fact, is SessionID in other containers may not be called Jsessionid up.

Cookies, session, SessionID and Jsessionid