Data is stored

The origin of the Cookie

Those of you who have studied HTTP know that HTTP is a stateless protocol that does not save state.

What is unsaved state?

  • The HTTP protocol itself does not store the communication status between the request and the response. The protocol itself does not retain information about all previous request or response messages, that is, a server does not know whether the same browser is accessing it. For example, if the Web page that requires login authentication cannot manage state itself (it does not record the logged state), then it must log in again every time it jumps to the page.
  • Therefore, Cookie technology is introduced to control the state of the client by writing Cookie information in the request and response messages.

The principle of cookies

Cookie composition (attributes)

  • Name: Cookie names are case insensitive, although in practice it is best to treat cookie names as case sensitive because some servers treat cookies this way. The cookie name must be URL-encoded.
  • Value: string value stored in cookie. The value must be URL-encoded. To decode must use decodeURIComponent() to decode.
  • Domain:
  • Path:
  • Expires/ max-age: By default, all cookies are deleted at the end of a browser session. But you can also set your own deletion time. Max-age is in seconds. When max-age is positive, cookies will be deleted after max-age seconds. When max-age is negative, cookies will only be stored in the browser memory and will only be valid in the open browser window or sub-window. Once the browser is closed, the cookie disappears.
  • Secure: When this property is set to true, this cookie is only transmitted (to the server) over secure protocols such as HTTPS and SSL.
  • HttpOnly: If this property is set to true, the value of the cookie (document.cookie) cannot be obtained from js scripts, effectively preventing XSS attacks.

Cookie restrictions

Cookies are bound by nature to a specific domain name. When a cookie is set, it is included in any request sent to the domain that created it. This restriction ensures that the information stored in the cookie can only be accessed by approved recipients and not by other domains.

  • Cookies cannot cross domains

    Cookies follow the same origin policy, each Cookie will be bound to a single domain name, only the Cookie set with the server domain name will be uploaded, cookies of other domain names will not be uploaded, and (cross-source) document. Cookie in the original web code can not read the Cookie under the server domain name.

session

In addition to storing user information in the browser through cookies, Session can also be used to store information on the server, which is more secure.

Sessions can be stored in files, databases, or memory on the server. Sessions can also be stored in an in-memory database such as Redis, which is more efficient.

The process of using Session to maintain user login status is as follows:

  • When a user logs in, the user submits a form containing the user name and password and sends it to the HTTP request packet.
  • The server verifies the user name and password, and if correct, stores the user information in Redis. Its Key in Redis is called Session ID.
  • The set-cookie header field of the response packet returned by the server contains the Session ID. After receiving the response packet, the client saves the Cookie value in the browser.
  • The Cookie value will be included when the client makes a request to the same server. After receiving the Cookie, the server extracts the Session ID and the user information from Redis to continue the previous business operations.

Note that the Session ID cannot be easily obtained by malicious attackers. In this case, you cannot generate an easily guessed Session ID value. In addition, Session ids need to be regenerated frequently. In scenarios with high security requirements, such as transfer of money, you need to use Session to manage user status and re-authenticate users, such as re-entering passwords or using SMS verification codes.

Cookie and Session selection

  • Different types of values are stored: Cookies can only store ASCII character strings. To set other types of data, you need to convert them into character strings. Session can store any type of data.

  • Security: Cookies are stored in a browser and can be viewed maliciously. If you want to store some privacy data in cookies, you can encrypt the Cookie value, and then decrypt it on the server;

  • For large web sites, it is very expensive to store all user information in a Session, so it is not recommended to store all user information in a Session.

    JSON Web Tokens

    The problem with this model is that it does not scale well. If it is a server cluster or a cross-domain service-oriented architecture, session data is required to be shared and each server can read sessions.

    For example, website A and website B are affiliated services of the same company. Now the requirement, as long as the user login in one of the websites, then visit another website will automatically login, how to achieve?

    One solution is to persist session data to a database or other persistence layer. Upon receiving the request, the various services request data from the persistence layer. The advantage of this scheme is the clear structure, but the disadvantage is the large amount of engineering. In addition, if the persistence layer fails, it will fail in a single point.

    Another option is that the server does not store session data at all; all data is stored on the client side and every request is sent back to the server. JWT is an example of such a scheme.

    Reference: www.ruanyifeng.com/blog/2018/0…

Web Storage

Purpose: To overcome some of the limitations imposed by cookies by not continually sending data back to the server when it needs to be tightly controlled on the client.

Goal:

  • Provides a way to store session data outside of cookies;
  • Provides a mechanism for storing large amounts of data that can exist across sessions.

Constructor Storage

Methods:

  • Clear () : deletes all values; It’s not implemented in Firefox.
  • GetItem (name) : obtains the value based on the specified name.
  • Key (index) : The name of the value at the index position.
  • RemoveItem (name) : Removes the name-value pair specified by name.
  • SetItem (name, value) : Sets a value for the specified name.

sessionStorage

The sessionStorage object is an instance of Storage

  1. Stores data for a session that only lasts until the browser closes.
  2. Data in sessionStorage can exist across page refreshes
  3. If the browser supports it, the browser crashes and restarts (Firefox and WebKit support it, Internet Explorer does not).

localStorage

The localStorage object is an instance of Storage

  1. LocalStorage localStorage for persistence, data will never expire unless actively deleted.
  2. Unlike globalStorage, you cannot assign any access rules to localStorage.
  3. To access the same localStorage object, pages must be from the same domain name (subdomains are invalid), using the same protocol, and on the same port. (The same origin policy)
  4. LocalStorage cannot automatically become invalid by setting the expiration time.

limit

  • For localStorage, most desktop browsers set a limit of 5MB per source. Chrome and Safari for every

The limit for one source is 2.5MB. Safari for iOS and WebKit for Android are also limited to 2.5MB.

  • Restrictions on sessionStorage also vary from browser to browser. Some browsers have no limit on the size of sessionStorage,

But Chrome, Safari, Safari for iOS, and WebKit for Android are all limited to 2.5MB. IE8+ and Opera limit sessionStorage to 5MB.

IndexedDB

.