A story that gives you an idea of how Http sessions and user logins work

If you’re new to THE HTTP protocol, you’ll hear a phrase called “stateless.”

In fact, in the interview often mentioned HTTP protocol, many students will be able to answer these two points: TCP based, stateless.

So what does stateless mean, and what about other concepts like sessions, cookie-based sessions, and JWT?

HTTP stateless

Simply put, statelessness is the absence of memory.

If you compare it to a person, that person has no memory, he can’t remember who he knows, what he did.

Or, take 🌰 of e-commerce, for example, there is an e-commerce company called “you ah” (know this classmate should be some age :), you on the website, add 10 items to the shopping cart, refresh the page, found the cart empty (may not think they have the kind of empty shopping cart god coupons……) If you have a bug adding to your shopping cart, how can you happily chop your hands? The engineers at Yes also saw the problem and decided to find a way to solve the stateless HTTP problem.

The session (session)

How do you remember which items each user added to the cart? Engineers think, the door of Baidu hot pot restaurant, every time is the boss Baidu took the book, when the guests order, she will write down different guests in the book, respectively ordered what dishes, e-commerce sites can also do so.

So, the engineer wrote a piece of code on the server side, and gave each visitor a file (session) on the computer to record all the items he joined. Well, perfect. Now you can record the contents of each customer’s shopping cart.

cookie-based session

After writing the code, engineer A submitted the merge request to Engineer B and prepared to make A cup of goji berry tea. B times before he could leave the engineer came running, said the plan there are serious problems, although there are session on the server to record the user’s shopping cart of goods, but still not solved, the user refresh the page, the server didn’t know before, during and after the refresh the page is the same person (the client) client problem, after all, Http is stateless.

A: After A while, the server can’t distinguish between the same client before and after refreshing the page, so I add something. After the server generates the session file, it sends the file path (session ID) back to the client. The client saves the path in the browser’s cookie. Send me that path every time, so I can find the last session file.

Image: sherryhsu.medium.com/session-vs-…

Once again, A perfectly solves the problem at hand.

After going online to run for A period of time, operation and maintenance C came to find little A and said, you have A problem with this logic. Too many files are generated on the server, and the disk space is filled up quickly! Little A thought, this is A problem, every time generates A new session file, even if the disk is cheap, can not hold long ah. Session files are automatically (or passively) deleted after the expiration date. This will reduce the pressure on server space.

Operation and maintenance C listen to, in case one day A short time outbreak of A large number of requests, or may be full of server disk, then also have to give small A wipe ass; In addition, it is also an issue that how to share sessions among multiple servers when the server is to be deployed in cluster. Accidentally recently heard A fashionable word called JWT, might as well call small A to Chou Chou can solve this problem.

JWT(JSON Web Tokens)

Little A read several JWT articles, think JWT is very good and powerful, directly kill the server created session file, directly sent the session file content to the client, anyway, they have A signature in it, not afraid of malicious users tamper with data, perfect! Say dry dry, small A pull one or two cut pages (may also be small A, after all, there are all dry engineers), cookies are dry, before and after the use of JWT user authentication, front-end with localStorage or sessionStorage in the browser, the space is bigger than the cookie, Perfect, but also to solve the CORS front-end security issues, perfect! Everything was perfect until…

  • One day, the user called the customer service of youah, his phone was stolen, and asked the customer service to log out of all the devices he had logged in before

  • On another day, the security group detects that a user access is abnormal and needs to know how many devices the user is in login state

Image: sherryhsu.medium.com/session-vs-…

conclusion

OK, pull so much nonsense, or a simple summary

HTTP session summary:

  • Http is stateless. Each request is independent. If you visit a website twice in a row in the same browser, Http does not know that both visits are to the same person (or client).

  • In real life, we need states, even if they last for a period of time (like the 15 seconds of memory in Aamir Khan’s “Unknown Death”).

  • To achieve stateful, sessions were invented to represent sequential sessions, and cookies were invented to maintain (recognize) sessions between the browser (client) and the server. If you store a session ID in a cookie, the server can use this session ID to find the corresponding session data

  • Later on, a number of experts pointed out that sessions add complexity to servers, such as sharing sessions between back-end clusters, and distributed session storage is a challenge. JWT was born. Instead of saving session data on the server (I think it is inevitable in most scenarios), send session data to the client, add a signature, and the secret key is only on the server, which greatly reduces the complexity and resources of the server on the basis of ensuring certain security. Of course, as mentioned above, there are some problems with the JWT scheme…

  • In addition, there are various custom so-called tokens, which are basically the same as the cookie-based session or JWT above

Summary of User Login

It is a bit embarrassing that the title of this article contains “user login”. It seems to have written here, but I found that the content of user login is not mentioned. However, if you have a good understanding of the above content, user login is easy.

Usually the back end provides a login interface, and the front end sends the user name, password, etc. After that, the main job is to store the token that the user has logged in. You can store this token in one of the following ways:

  • Usually we have session data whether the user is logged in or not. So, of course, we can do this, right after the user logs in, just in the normal session, add the ID of the currently logged in user or something like that. When a subsequent request arrives at the server, it can determine whether the user is logged in by simply checking whether there is a user ID in the session.

  • Some websites have different expiration times for common session and user login status. Or for greater security, such as cookies involving user logins, set attributes such as httpOnly Secure Samesite separately. Therefore, it is necessary to separate the session from the ordinary session, and set a login cookie, is also one way, but the implementation is a little more complicated than the first solution

  • JWT, once you’ve logged in, you put your user ID in JWT and send it to the front end. Personally, I do not recommend the inclusion of user permissions in JWT. I think JWT should store as little data as possible, since it’s public (though you can encrypt it) and increases the HTTP header size.

The relevant data

  • JWT’s official website

  • Ruan Yifeng introduction to JWT

  • Session vs Token Based Authentication

Wechat subscription number

Welcome to pay attention to the wechat subscription number [front end test Baodian.com], we will frequently update the front end test related interview topic articles, as well as the front end related technical articles to share.

Micro channel small program

At the same time, we also welcome you to visit our wechat mini program, which aims to provide interview questions collection and arrangement for the front end interviewers, and provide free online mock interview service.