Comic | Kill the session, it's so cool!

Thirty years ago, I found a good job and my life was very leisurely.

Yes, I am an HTTP server. My creators treat me very well. The HTTP protocol they developed is super simple, which is a request <---> response.

I particularly like the statelessness of the HTTP protocol :

Statelessness is determined by the business. The Web 30 years ago was basically the browsing of documents. Since it was browsing, as a server, why should I remember who viewed what documents in a period of time?

But the good days didn't last long. Interactive Web quickly emerged, forums, shopping, chat and other websites all required me to remember a person's login status.

I have no choice but to give each logged-in a man-made box and put the things I want to put in each application.

This method called session can distinguish login users, and everyone is very happy.

However, each browser only needs to save its own session id, and I need to save everyone's session id! If there are more people visiting me, there will be thousands or even hundreds of thousands.

Some nonchalant guys still stuff things into the box frantically!

Actually put a huge shopping cart in the session.

This is a huge expense for me, I have to build a new house

Soon, trouble came

There are more and more things like this, no way, I have to copy the session

Later, I met a guy called Redis and asked me to store them centrally.

Although Redis's new scheme is good, it increases the possibility of a single point of failure. If the Redis machine goes down, everyone will have to log in again, which is estimated to be scolded to death.

I also tried to make this single point machine into a cluster to increase reliability, but anyway, this small session is a heavy burden for me.

But letting the client keep the state information has a big security loophole, and those with bad intentions may forge the box.

The key point is verification. I have to add a little information to this box to prove that I created it.

How to achieve it? This guy Https gave me a trick:

Then put this signature and the previous data together to form something called Token.

I don't save the token on the server side. When the client sends the token, I just use the same algorithm to do a verification.

If it is the same, I know that this person has logged in, and can get his user id directly.  

If they are not the same, the data must have been tampered with, then I'm not welcome.

Since then, I no longer have to maintain the numerous boxes, and I have returned to the original good time: stateless.

Validating the token adds a bit of computational overhead, but the silly boy Agan CPU runs so fast, this calculation is nothing to him.

However, everything is a double-edged sword.

Token soon encountered problems

After a while, this guy came to find me again

With the expiration date, I can check whether the token has expired.

But this kid is very persistent. He has to log out immediately and invalidate the Token immediately on the server side. The validity period is not good and I am mad at me.

I was so anxious that I had to write a blacklist on the wall

It seems that it is almost impossible to kill the session on the server side and kill the state!

More exciting technical comics , all in the programmers stand up

Guess you like

Origin blog.csdn.net/coderising/article/details/112645885