This article will help you distinguish between Cookie and Session

Cookies and Sessions

The HTTP protocol is a stateless protocol , that is, every time the server receives a request from the client, it is a brand new request , and the server does not know the client's historical request records;

  • The main purpose of Session and Cookie is to make up for the stateless characteristics of HTTP

1. What is Session?

The client requests the server , and the server will open up a memory space for this request . This object is the Session object , and the storage structure is ConcurrentHashMap. Session makes up for the stateless nature of HTTP. The server can use Session to store some operation records of the client during the same session .

1.1. How to determine whether Session is the same session?

When the server receives the request for the first time, it opens up a Session space (creates a Session object) , generates a sessionId, and sends the required settings to the client through the **Set-Cookie: JSESSIONID=XXXXXXX** command in the response header. Cookie response; After the client receives the response, it sets a cookie information of **JSESSIONID=XXXXXXX** on the local client. The expiration time of the cookie is the end of the browser session ;

img

Next, every time the client sends a request to the same website , the request header will bring the Cookie information (including sessionId). Then, the server reads the Cookie information in the request header, obtains the value named JSESSIONID, and obtains this time. Requested sessionId .

1.2. Disadvantages of Session

The Session mechanism has a shortcoming . For example, server A stores the session. After load balancing is performed , if the number of visits to A increases sharply within a period of time, it will be forwarded to B for access. However, server B does not store the session of A, which will cause the session to fail. of failure .

2. What are Cookies?

Cookies in the HTTP protocol include Web Cookies and browser Cookies , which are a small piece of data sent by the server to the Web browser. The cookie sent by the server to the browser is stored by the browser and sent to the server with the next request. Usually, it is used to determine whether two requests come from the same browser, such as when the user remains logged in .

The HTTP Cookie mechanism is a supplement and improvement of the stateless HTTP protocol.

2.1. Cookies are mainly used for the following three purposes:
  • Session management
    Logins, shopping carts, game scores, or anything else the server should remember

  • Personalization
    User preferences, themes or other settings

  • Tracking
    Record and analyze user behavior

Cookies were once used for general client-side storage . While this is legal as they are the only way to store data on the client, it is recommended these days to use modern storage APIs . Cookies are sent with every request, so they may reduce performance (especially on mobile data connections).

2.2. Create Cookie

When receiving an HTTP request from a client, the server can send a Set-Cookie header with the response . The cookie is usually stored by the browser , and then the cookie is sent to the server along with the HTTP header.

Set-Cookie and Cookie headers

The Set-Cookie HTTP response header sends cookies from the server to the user agent. The following is an example of sending a cookie

Insert image description here

This header tells the client to store the cookie

Now, with every new request to the server, the browser will send all previously stored cookies back to the server using the Cookie header.

There are two types of Cookies, Session Cookies and Persistent Cookies .

  • If a cookie does not contain an expiration date, it is considered a session cookie. Session cookies are stored in memory, never written to disk , and are permanently lost when the browser is closed .
  • If a cookie contains an expiry date , it is considered a persistent cookie . On the expiration date specified, the cookie is deleted from disk.

There is also the Secure and HttpOnly tags of Cookie , which are introduced in turn below.

2.3. Session Cookies

The above example creates a session cookie. The session cookie has a characteristic that the cookie will be deleted when the client is closed because it does not specify the Expires or Max-Age directive.

However, web browsers may use session restore, which causes most session cookies to remain persistent, as if the browser was never closed.

2.4. Permanent Cookies

Persistent cookies do not expire when the client is closed, but expire outside of a specific date (Expires) or a specific length of time (Max-Age). For example

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
Cookie Secure and HttpOnly tags

Secure cookies need to be sent to the server in an encrypted manner through the HTTPS protocol. Even if secure, sensitive information should not be stored in cookies because they are inherently insecure and this flag provides no real protection.

2.5. The role of HttpOnly
  • The lack of the HttpOnly attribute in the session cookie will allow the attacker to obtain the user's cookie information through programs (JS scripts, Applets, etc.) , causing the user's cookie information to be leaked and increasing the attacker's cross-site scripting attack threat .

  • HttpOnly is Microsoft 's extension to Cookie . This value specifies whether the Cookie can be accessed through client scripts.

  • If the HttpOnly attribute is not set to true in the cookie , the cookie may be stolen . Stolen cookies can contain sensitive information that identifies site users, such as ASP.NET session IDs or Forms authentication tickets. Attackers can replay stolen cookies in order to disguise themselves as users or obtain sensitive information, conduct cross-site scripting attacks, etc.

2.6. Scope of Cookies

The Domain and Path identifiers define the scope of the Cookie: that is, which URLs the Cookie should be sent to.

The Domain identifier specifies which hosts can accept cookies. If not specified, the default is the current host** (excluding subdomain names) . If Domain** is specified , subdomain names are generally included.

For example, if you set Domain=mozilla.org , the cookie is also included in the subdomain (such as developer.mozilla.org).

For example, if Path=/docs is set , the following addresses will match:

  • /docs
  • /docs/Web/
  • /docs/Web/HTTP
2.8. Comparison between JSON Web Token and Session Cookies

JSON Web Token , JWT for short , and Session can both provide user identity authentication for websites, but they are not the same thing.

2.9. Similarities between JWT and Session Cookies

Before discussing JWT and Session Cookies , it is necessary to understand their similarities.

They can be used to authenticate users both when they click through to different pages and after they log into a website or application .

Without these two, you may need to log in every time you switch pages. Because HTTP is a stateless protocol. This means that when you visit a web page and then click on another page on the same site, your previous actions will not be remembered in the server's memory.

img

Therefore, if you log in and visit another page that you have access to, you will be logged in again since HTTP does not record the information you just logged in to.

2.10. JWT and Session Cookies are mechanisms used to handle switching between different pages and save user login information.

In other words, both technologies are used to save your login status and allow you to browse any password-protected website. This problem is solved by authenticating user data every time a new request is made.

So what are the similarities between JWT and Session Cookies? That's a mechanism that allows them to record and verify your login status between requests.

2.11. What are Session Cookies?

Session Cookies are also called session cookies . In Session Cookies, the user's login status will be saved in the server's memory. When the user logs in, the Session is securely created by the server .

At each request, the server will read the SessionId from the session cookie. If the data on the server side is the same as the read SessionId, then the server will send a response to the browser to allow the user to log in.

img

YmxvZ3MuY29tL2Jsb2cvMTUxNTExMS8yMDIwMDQvMTUxNTExMS0yMDIwMDQwNTA5MDQ1NjgxNi0xNTY3MjYxODE0LnBuZw?x-oss-process=image/format,png)

Guess you like

Origin blog.csdn.net/H931053/article/details/134827166