Cookie

A Cookie is a small piece of data that the server sends to the user’s browser and keeps locally. It is carried and sent to the server the next time the browser makes a request to the same server.

Cookies were originally designed to compensate for the stateless nature of HTTP

Why is statelessness a defect?

For example, if I buy a pair of clothes and pants on a shopping site, when I finally check out, due to the statelessness of HTTP, the server doesn’t know what I bought unless I do something extra

And that’s where the Cookie comes in and when I send a request to the server I send a Cookie that contains information about the product

So the server knows what I bought and doesn’t that solve the HTTP statelessness problem

Another common use scenario of cookies is that when logging in to a website, the website will ask the user to enter the user name and password. There is usually an option for automatic login next time, and the user will automatically log in next time he/she visits the same website. This is because when the user logs in for the first time, the server has already sent a Cookie with login credentials (some form of encryption of username and password) to the user’s hard drive. If the Cookie is not expired for the second login, the browser will send the Cookie and the service will authenticate the user to log in

set-cookie

The server typically sends Cookie information using the set-cookie field in the response header

// Node.js
response.setHeader("Set-Cookie"."
      
       =
       
        ; Max-Age=
        
         ; Secure "
        
       
       );
Copy the code

Cookies have some special properties to be aware of

Max-age helps determine whether a Cookie is expired

The HttpOnly attribute has no value

Cookie API cannot access cookies with the HttpOnly attribute. This type of cookie applies only to the server

Secure cookies should only be sent to the server through requests encrypted by THE HTTPS protocol

SameSite cookies allow the server to request that a Cookie not be sent during cross-site requests

Set-Cookie: key=value; SameSite=Strict
Copy the code

SameSite has three values

  • None. Browsers continue to send cookies under same-site and cross-site requests, case insensitive.
  • Strict. The browser will only send cookies when visiting the same site. (Strengthening of restrictions on existing Cookies, as described in “scope of Cookies” above)
  • **Lax. * * andStrictSimilar, except when the user navigates to a URL from an external site (for example, via a link). In newer browsers, same-site cookies will be reserved as the default for cross-site sub-requests, such as image loads or calls to frames, but will only be sent when the user navigates to a URL from an external site. If the link link

SameSite = lax

Let’s see an example that illustrates lax and strict in a graphic way. Let’s say John wrote a blog post that included an amazing image of 🐱 hosted at /blog/img/amazing-cat.png. One day John saw it and thought it was amazing So he used it directly on his blog, with a link to John’s original post.

Later, Wang Wu visited my blog and took a promo_shown cookie. So when he visited Li Si’s blog and saw the photo request of Amazing Cat, he would definitely bring this cookie, didn’t he? The cookie of promo_shown is not at all useful when visiting Li Si’s blog, so why add the request header

In this case, if the promo_shown cookie is set as follows:

Set-Cookie: promo_shown=1; SameSite=Lax
Copy the code

So when Wang Wu visits Li Si’s blog, the browser requests Kaiman-CAT will not send a cookie. However, if Wang Wu clicks a link to Zhang SAN’s original article, the request will contain a cookie. Lax can improve the webpage loading performance to some extent

If we change the promo_shown cookie to strict:

Set-Cookie: promo_shown=1; SameSite=Strict
Copy the code

So when someone sends a cookie through an external 🔗 such as an email or a link to Joe on Joe’s website, the cookie will not be sent in the initial request

Strict scenarios are generally used to change passwords or place an order and pay

Cookie shortcomings

  1. Capacity defects. Cookies have a maximum size of 4KB and can only be used to store small amounts of information.

  2. The same domain name requests always come with a full cookie as the number of requests increases or creates a performance waste that Path may be able to address

  3. Security CSRF XSS

LocalStorage

Similar to cookies, localStorage is used to store data under the current domain name, but it is important to note that only localStorage in the same source is the same

LocalStorage is a persistent storage of data for a domain name that will not be erased even after the session ends

LocalStorage is typically stored as key-value pairs, which are always stored as strings.

Grammar:

localStorage.setItem('myCat'.'Tom');
let cat = localStorage.getItem('myCat');
Copy the code

LocalStorage VS Cookie

  1. The capacity of Chrome LocalStorage is 5M

  2. It only exists on the client to improve performance and avoid security problems

SessionStorage

Session stands for session so the sessionStorage will empty after the session ends

The encapsulation of the interface is the same as localStorage

LocalStorage VS SessionStorage

LocalStorage The same as sessionStorage Capacity upper limit storage mode The operation mode is the same

But the latter is not there when the session ends and the former is persistent