The distinction between cookies and sessions is a frequently asked question in entry-level interviews. If you’re just answering the difference mechanically, then you probably don’t really understand cookies and sessions, let alone use them flexibly.

This article takes you through the basics of cookies and sessions to the more advanced ones and shows you how much you don’t know.

What is a Cookie?

We know that HTTP protocol is stateless, a request completed once, does not persist the request and the corresponding information. Then, in scenarios such as shopping cart, user login status, page personalization, etc., the information of a particular user cannot be recognized. That’s where the Cookie comes in.

Cookie is a mechanism for clients to save user information. The data sent from the server to the browser is saved locally and sent to the same server in the next request. For cookies, you can set an expiration time.

Typically, cookies are used to tell the server whether two requests are from the same browser, such as to keep the user logged in. This solves the HTTP stateless problem.

Cookies are mainly used for the following:

  • Session state management (such as user login status, shopping cart, game score, or other information that needs to be logged)
  • Personalization (such as user-defined Settings, themes, etc.)
  • Browser behavior tracking (e.g. tracking and analyzing user behavior, etc.)

Cookies are stored on the client side, which means that they can be modified in some way to fool the server. How to solve this problem? So that introduces sessions.

What is Session?

Session Indicates the Session between the server and the client.

Wikipedia explains: In computer science, especially in networking, a session is a persistent network protocol that creates associations between the user (or user agent) side and the server side to exchange packets of data. Session is an important part of network protocols (such as Telnet or FTP).

In contrast to cookies, a Session is a mechanism for storing data on the server. It is a data structure used to track user status. It can be stored in a file, database, or cluster.

When jumping between Web pages of an application, variables stored in the Session object are not lost, but persist throughout the user Session. The Session ends when the client closes the Session or the Session times out.

Currently, most applications use cookies to implement Session tracking. When a Session is created for the first time, the server will record the SessionID in the Cookie by sending it back to the client in THE HTTP protocol. In subsequent requests, the server will pass the SessionID to the server so that each subsequent request can identify who you are.

The difference between cookies and sessions

The difference between a Cookie and a Session is often asked in an interview.

  • The scope is different. Cookies are stored on the client (browser) and sessions are stored on the server.
  • Different access modes, Cookie can only save ASCII, Session can save any data type, such as UserId.
  • Cookies can be set to last for a long time. For example, for the default login function, the Session generally lasts for a short time and becomes invalid when the client is shut down or the Session times out.
  • The privacy policies are different. Cookies are stored on clients and information is easy to be stolen. Sessions are stored on the server, which is relatively secure.
  • The storage size is different. The data saved by a single Cookie cannot exceed 4K. The Session can store much more data than cookies.

What happens if cookies are disabled?

What if the customer has cookies disabled in the browser?

Scheme 1: Concatenate the SessionId parameters. Concatenate sessionids in GET or POST requests. GET requests are usually concatenated with parameters following the URL. POST requests can be placed in the Body. Either form needs to be consistent with server fetching.

This scheme is quite common, such as foreign websites, often prompt whether to enable cookies. If you do not click on consent or authorization, you will find that the URL path of the browser often has “? SessionId = 123ABC “.

Scheme 2: Based on tokens. Tokens are often used in APP applications to interact with servers. Token is essentially a unique string returned by the server after successful login to identify the temporary authorization of the client. The client stores the Token and sends it to the server in HTTP headers for subsequent requests, which can be used to verify the identity of the requesting user.

How are sessions handled in distributed systems?

In distributed systems, there are often multiple servers handling the same business. If the user logs in from server A and the Session is on server A, the next request will be allocated to server B, and the login will be invalid.

For similar scenarios, there are three solutions:

Plan 1: Request accurate location. That is, the load balancer allows user requests from the same IP to always be assigned to the same service. Nginx’s IP_hash policy, for example, can do this.

Scheme 2: Session replication and sharing. The goal of this solution is to ensure that sessions are consistent across all servers. Most mainstream Web servers, such as Tomcat, use Session replication to realize Session sharing.

Scheme 3: Based on shared cache. The solution is to put the Session in a common place and fetch it from each server when it is used. For example, it is stored in Redis, Memcached, and other caching middleware.

Session sharing can be easily implemented in Spring Boot projects if Redis is integrated.

Same-origin policy and cross-domain request

The so-called “same origin” refers to the “three same” : the same protocol, the same domain name, and the same port. If these three are identical, they’re homologous.

The same origin policy ensures user information security and prevents malicious websites from stealing data.

For example, A user visits the bank website A and then browses other websites. If other websites can read the Cookie of A, the privacy information will be disclosed. What’s more, cookies are usually used to save the user’s login status, which can lead to impersonating the user. Therefore, the same origin policy is required, and if cookies can be shared, the Internet is not secure at all.

The same origin policy provides some security, but it can also be inconvenient in some scenarios, such as common cross-domain request problems.

In HTML, tags such as <a>,<form>, <img>, <script>, <iframe>, <link>, and Ajax can all point to a resource address. A cross-domain request is a request from a different domain than the one to which the request is directed. Same-origin is same-domain, and a cross-domain request occurs when one of the three items is different.

Browsers restrict cross-domain requests because cross-domain requests can be used to launch CSRF attacks.

Cross-site Request Forgery (CSRF) is also known as one Click Attack/Session Riding. CSRF attacker induces the user to visit an attack page after the user has logged in to the target website, takes advantage of the target website’s trust to the user, launches forged user operation request to the target website on the attack page as the user, and achieves the attack purpose.

There are usually the following methods for cross-domain requests:

  • Avoiding cross-domain requests through proxies;
  • Cross domain via Jsonp;
  • Through cross-domain resource sharing (CORS);

Specific steps for cross-domain resolution are not expanded.

summary

When preparing interview questions, we usually just memorize the difference between Cookie and Session. But only systematic learning can be more profound knowledge points in series, forming a strong memory, the effect of mastery. For example, this paper understands the causes of Cookie and Session, the problems solved and what problems will be brought after their introduction, so as to have a more systematic and comprehensive grasp of this knowledge point.

About the blogger: Author of the technology book SpringBoot Inside Technology, loves to delve into technology and writes technical articles.

Public account: “program new vision”, the blogger’s public account, welcome to follow ~

Technical exchange: Please contact the weibo user at Zhuan2quan