1 minutes take you to understand Java Web developers must master: Token, Cookie, Session

In Web applications, HTTP request is stateless. That is: the user first initiated the request, the server connection is established and the login is successful, every time you open a page in order to avoid the need to log it, appeared cookie, Session.

Cookie

Cookie is a mechanism for the user to save the client information, some of the information used to record the user, but also a way to achieve the Session. Cookie limited amount of data stored, and are stored in the client browser. Different browsers have different storage sizes, but generally not more than 4KB. Therefore, the use of Cookie fact can only store a short text message.

For example: visit the website, now enter a user name password, and then open the next day in many cases directly open. This time a mechanism used is Cookie.

Session

Session state is another mechanism for a customer record, which is a data structure (mainly stored stored on the server and Session SessionID content, but also contains a lot of custom content such as: basic user information, authority information, the user means information, fixed variables, etc.), this data may be stored in a cluster, database, file, to track the status of the user.

The client browser access to the server, the server to the client information recorded on the server in some form. This is the Session. Just look for the Session of the client when the client browser access again from the state on it.

After the first time the user logs on, the browser sends the user information to the server, the server creates a SessionId for the user, and the response content (Cookie) together in the SessionId returned to the browser, the browser will store this data locally. When a user sends a request again, the browser will automatically put the last request Cookie stored data is automatically carried to the server.

After the server receives the request information, determines the data requested by the browser in which SessionId current user, and then returned to the browser of the user acquired in accordance SessionId Session Session data repository.

For example: shopping carts, added at the client after the commodity can know which items added, and the server how to distinguish it, so it needs to store some information on the use of the Session.

If the Cookie mechanism to determine the identity of the customer by checking the customer who "pass", then Session mechanism is used to confirm the identity of customers through "customer list" to check on the server. Session equivalent program created on the server of a customer files, customer visit when the customer files only need to query the table on it.

Session after generation, as long as users continue to access, the server will update the last access time Session, and to maintain the Session. To prevent memory overflow in the server will no longer be removed from the active Session memory. This is the time Session of the timeout. If you exceed the time-out did not visited server, Session automatically ineffective.

Token

HTTP requests are butted to form stateless. That HTTP server does not know this request and the last request is associated. So there will be the introduction of Session, namely the server and the client save a piece of text, every time a client requests are initiated with, so the server knows whether the client had initiated the request.

Thus, resulting in frequent client request data to the server, the server frequent queries to the database user name and password and compared to determine the user name and password are correct or not. The Session is the need of storage space, frequent queries to the database server caused a lot of pressure.

In this case, Token born applications.

Token is a series of strings, the server generates, as a token to the requesting client. When the client first visit to the server, the server will be based on a unique identification pass over the userId, we use some algorithm, plus key, generate a Token, and then look through the BASE64 encoding after the Token returned to the client, Token end will be saved (can be saved by a local database or file form). When the next request, the client only need to bring the Token, the server receives a request, using the same algorithm and key to verify Token.

The easiest Token Composition: uid (user's unique identity), time (timestamp of the current time), sign (Signature by several former salt + hash algorithm to compress into a certain length of hexadecimal characters Token string, a malicious third party can be prevented splicing Token requesting server).

Use the Token-based authentication methods, logon recorded in the server does not need to store the user. Probably the process is this:

  • The client uses the user login name with the password request

  • Server receives a request to verify the user name and password

  • After successful authentication, the server will issue a Token, then the Token is sent to the client

  • After receiving the client Token it can be stored, such as on a Cookie or database

  • Every time a client requests a resource to the server needs with the server issued Token

  • Data server receives the request, and then to verify that the client requests inside with the Token, if authentication is successful, it is returned to the client's request

When APP log transmits the encrypted user name and password to the server, the server to authenticate the user name and password, if successful, in some way, such as a randomly generated 32-bit string as a Token, is stored in the server, and returns the Token to the APP, after APP when requested, those who need to verify where we must bring the Token, and then the server-side validation Token, successfully returns the desired results, failure to return an error message, let him log in again.

For an APP with the same handset is currently only one Token; phone APP will store a currently valid Token. Wherein the server provided a valid Token, each time a request APP Token and validity are verified.

The following example can be well understood:

"I'll have pancakes (token I am your noodle stand selling grilled on a cold, scope credit)", "good", "eggs (token I am your noodle stand selling grilled on a cold, scope credit) '' good '' and then add eggs (I'm your token of the cold noodle stand selling grilled, scope credit), "" good "to get a final ordinary pancakes, plus two eggs ...... If the server is restarted or because of other reasons, the server has been saved token is lost . Then the user needs to log in again and certification. "I'll have pancakes (token I were you selling grilled noodles for the noodle)" "...... that I have not seen you."

Guess you like

Origin juejin.im/post/5df63bddf265da33a413ddb9