As one of the three traditional e-commerce giants (the others include Alibaba and Pinduoduo), Dongzi’s interview questions are quite difficult. Generally speaking, the interviews are not as difficult as the other two, and of course the salary is not as high as the other two. .

Among them, Pinduoduo’s salary is the most outrageous, especially in the past few years. I heard that for poaching fellow developers, the salary can be two to three times the original salary, which is really abnormal (but I like it).

Dongzi’s interview questions are as follows:

picture

The answers to most of the interview questions can be found on my website (www.javacn.site), so I won’t go into details here. Let’s just talk today: What are the differences between Cookie, Session and Token?

1.What is the difference between Cookie, Session and Token?

Cookies, Sessions and Tokens are usually technologies used to save user login information, but there are big differences between the three. Simply put, Cookies are suitable for simple state management, Sessions are suitable for scenarios where users need to protect sensitive information, and Tokens Suitable for state-independent authentication and authorization.

Token state-independent analysis: In the traditional session-based authentication method, the server needs to save the user's session state on the backend and manage the session through Session ID. The Token mechanism does not need to save any status information about the user on the server. It only needs to generate a unique Token value through a certain algorithm when the login is successful, and then send this Token to the client for storage (stored in localStorage or sessionStorage). Note that the server does not store the Token value at this time. The server only verifies the Token without saving it. This is called "state irrelevance". This can reduce the burden of storing and managing session state on the server, so it is more suitable for large systems and distributed systems.

Specifically, the differences between Cookie, Session and Token mainly include the following differences:

1. Storage locations are different: Cookies are stored on the client side, that is, text files in the browser, and are communicated by passing them to the server in the HTTP header; Session is a server-side storage method, usually stored in the server's memory or database; Token is also stored On the client side, but usually stored in an encrypted manner in the client's localStorage or sessionStorage.
2. Data security is different: Cookies are stored on the client side and may be stolen or tampered with, so the storage of sensitive information needs to be encrypted; Sessions are stored on the server side, and are associated between the client and the server through a Session ID. Avoid direct exposure of sensitive data; Tokens are usually generated using encryption algorithms, have a short validity period and are one-way irreversible, which can provide higher security.
3. Different cross-domain support: In order to prevent security incidents, cookies do not support cross-domain transmission, that is, cookies under different domain names cannot access each other; and the Session mechanism usually saves the Session ID through Cookie, so the Session ID defaults to In this case, cross-domain is not supported; but Token can easily achieve cross-domain, because Token is stored in the localStorage of the client or sent to the server as part of the request header, so the transmission of Token information of different domain names is usually not affected.
4. State management is different: Cookie is a mechanism used by applications to implement state management by storing temporary data on the client; Session is a way for the server to record user status. The server will assign a unique Session ID to each session and Associate it with user status; Token is a mechanism used for authentication and authorization, usually representing the user's identity information and permission information.

2. What is the relationship between Cookie and Session?

To be precise, the implementation of Cookie has nothing to do with Session, but the implementation of Session requires the help of Cookie.

The implementation process of the Session mechanism is as follows:

1. Session creation: Normally, when a user logs in successfully, the server will create a new session for the user. During session creation, the server generates a unique identifier for the session, usually called a Session ID.
2. Session ID delivery: The server sends the generated Session ID to the client in a response, and uses the SetCookie command to save the user's Session ID in a cookie, usually a cookie named JSESSIONID.
3. Session data storage: On the server side, Session data will be stored in a data structure that can be associated with the Session ID (such as memory, database or file storage, etc.). A common way is to use the Session ID as a key to associate it with the corresponding Session user identity data.
4. Session ID verification and retrieval: When the user sends a new request, the client will carry the previously stored Session ID in the cookie or request header of the request and send it to the server. The server will find the corresponding Session data based on the Session ID to obtain the user's status information.
5. Session data usage: After the server obtains the Session data, it can read, modify or delete the status information saved in it according to specific needs. The server can manage the user's login status, shopping cart content, user configuration, etc. through Session.
6. Session expiration and destruction: Session has a validity period, which is usually marked as expired by setting a fixed time, or when there is no user activity within a certain period of time. When the Session expires, the server will destroy the corresponding Session data and release memory or other resources.

So by default, Session uses Cookie to complete the transfer of identity, so that the server can associate the Session ID with the saved session information to find a specific logged-in user, so: By default, Session The mechanism relies on Cookie implementation.

3. Can Session still be used after disabling cookies?

From the above we know that the Session mechanism relies on Cookie by default. So after disabling Cookie, will the Session mechanism become unusable? actually not.

In addition to using Cookie to pass the Session ID by default, we can pass the Session ID by ourselves through some special means to get rid of the situation where the Session cannot be used after disabling Cookies, such as the following two implementation methods:

1. URL Rewriting: You can append the Session ID parameter to the URL of each request. When the server receives the request, it parses the Session ID in the URL and associates it with the corresponding Session data. This method is suitable for situations where parameter passing in the address bar is not disabled.
2. Hidden form fields: The Session ID can be passed to the server as a method of hiding form fields. When the user submits the form, the Session ID will be sent to the server along with the form data, and the server will establish an association with the current session.

Through the above methods, the Session ID can be passed to the server side (although it is troublesome), and then on the server side, we obtain and map the Session ID passed above, so that the work of passing and matching logged in users is manually completed. The Session mechanism has to continue to be used.

summary

Cookies, Sessions and Tokens are usually technologies used to save user login information, but they are very different: Cookies are suitable for simple state management, Sessions are suitable for scenarios where user sensitive information needs to be protected, and Tokens are suitable for state-independent scenarios. Authentication and authorization. By default, Session uses the Cookie mechanism to pass the Session ID, but when Cookie is disabled, the Session ID can still be passed using special means, and the Session mechanism can still be used. Token does not save session information on the server side, so it is more suitable for large projects and distributed projects.