preface

Long time no see, friends. I haven’t updated it for more than a year. I didn’t expect to receive so many messages and concerns. Thank you for your support all the time. Recently, our team partners also developed a small, process, sequential front end test treasure book, including more than 600 front end questions, hoping to help partners on the way to interview.

Let’s get down to business. Hope you enjoy it

A story to help you understand how Http sessions and user logins work

If you are new to HTTP, you will hear the phrase “stateless”.

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

So, what does stateless mean, and what about other concepts it leads to, such as session, cookie-based session, and JWT?

HTTP stateless

Simply put, stateless means no memory.

If compared to a person, that person is no memory, he can not remember the people he knows, what has done.

Or, for example, 🌰, an e-commerce company called “You ah”), you go to the website, add 10 items to your shopping cart, refresh the page, and find your cart is empty (you might think you’ve got a magic trick to empty your cart). , even add shopping cart have a bug, this also how happy chop hands? The engineers at Yup noticed the problem and decided to come up with a solution to HTTP statelessness.

The session (session)

So how do you remember what each user added to the cart? The engineer thought, 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 what dishes, e-commerce website can also do so.

So the engineer, on the server side, wrote a piece of code and gave each visitor a session on the computer to keep track of all the items he added. Well, perfect, now you can record the contents of each guest’s shopping cart.

cookie-based session

Engineer A submits the Merge Request to Engineer B after he has written the code and is ready 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 thought for A while, the server could not distinguish the same client before and after refreshing the page, so I added something. After the server session file is generated, I send the file path (session ID) back to the client, and the client saves this path in the browser local (cookie). And every time you send that path back to me, I can find the session file from the last session.

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

Once again, A perfectly solves the problem at hand.

After running online for A period of time, operation and maintenance C came to find small A and said, you have A problem with this logic, too many files have been generated on the server, and the disk space has been occupied! “This is A problem,” A thought. “Every time A new session file is generated, even if the disk is cheap, it can’t hold for A long time.” Add an expiration date to these session files and then delete them automatically (or passively).

Operation and maintenance C listen to, in case which day A short time to break out A large number of requests, or the server disk may be full, then also have to wipe the ass for small A; In addition, it is also a problem how to share sessions among multiple servers in the subsequent preparation for cluster deployment of the server. Just happened to hear A fashionable word called JWT recently, might as well ask A to see if you can solve this problem.

JWT(JSON Web Tokens)

After reading several articles of JWT, little A felt that JWT was very good and powerful. He directly killed the session file created by the server, and directly sent the session file content to the client. Anyway, he had A signature in it, and he was not afraid of malicious users tampering with data. Say dry dry, small A pull one or two cut page (may also be small A himself, after all, there is A full dry engineer), cookie are dry, front and back end use JWT user authentication, front-end use localStorage or sessionStorage in the browser, the space is larger than cookie, It’s perfect. It can also solve those front-end security problems of CORS, Perfect! Everything was perfect until…

  • One day, the user called the customer service of “you ah”, his mobile phone was stolen, and asked the customer service to log out of their previous devices

  • 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, so much nonsense, let’s just summarize

HTTP session summary:

  • Http is stateless, each request is independent, you visit the same web site in the same browser two times in a row, Http does not know that both visits are by the same person (or client)

  • In reality, we need states, and even if they last for a while, it makes sense (as in the case of aamir Khan’s 15 seconds of Unremembered Death).

  • In order to achieve “stateful”, session was invented to represent sequential sessions, and cookie was invented to maintain (recognize) sessions between browser (client) and server. A session ID is saved in the cookie, and the server can find the corresponding session data according to this session ID

  • Later, some experts said that sessions increased the complexity of the server side, such as sharing sessions between back-end clusters, and distributed session storage is also a challenge. JWT was born. Instead of saving session data on the server (which I feel is inevitable in most scenarios), send session data to the client, add a signature, and the secret key is only available on the server. In this way, on the basis of ensuring certain security, the complexity of the server and the resources of the server are greatly reduced. Of course, there are some problems with the JWT scheme as mentioned above…

  • In addition, there are various customized so-called tokens, whose principle is basically the same as the cookie-based session or JWT above

User Login Summary

It is a little embarrassing that the title of this article contains “user login”, as if I had written here, I found that there is no content about user login. However, if you can understand the above content, user login is easy.

Usually the back end provides a login interface. The front end sends the user name, password and so on. After that, the main job is to store the token that the user has logged in.

  • We usually have session data regardless of whether the user is logged in or not. So, of course we can do this, after the user logs in, just add the ID of the current user in the normal session or something. When the subsequent requests arrive at the server, we only need to check whether there is a user ID in the session to determine whether the user has logged in (this scheme is usually implemented in some internal systems, after all, it is easy to implement).

  • Some websites have different expiration times for normal sessions and user login states. Or for greater security, such as cookies involving user logins, separate properties such as httpOnly Secure Samesite. Therefore, a separate session is required to be distinguished from the ordinary session. Setting a separate login cookie is also a way, but the implementation will be a little more complicated than the first method

  • JWT, after login, put the user ID in JWT and send it to the front end. I personally do not recommend including user permissions and other information in JWT; I think JWT should store as little data as possible, since this is public (although you can encrypt it) and also increases the HTTP header size.

The relevant data

  • Front end test treasure book

  • JWT’s official website

  • Ruan Yifeng JWT tutorial

  • Session vs Token Based Authentication

The last

Finally, we can not help playing a wave of advertising, but also welcome you to pay attention to our another diggings account front end test treasure dictionary, we will regularly update the front-end interview related test highlights and technical articles to share.