


Development History
1. A long time ago, the Web was basically just browsing documents. Since it is browsing , as a server, there is no need to record who has browsed what documents in a certain period of time. Each request is a new HTTP protocol, which is a request plus a response. Especially I don’t need to remember who just sent an HTTP request. Every request Both requests are new to me. It’s a very exciting time.
2. However, with the rise of interactive web applications, such as online shopping websites, websites that require login, etc., we immediately face a problem, that is, to manage sessions, we must remember who logs in to the system. Who puts items in their shopping cart, that is to say, I have to distinguish each person, which is a big challenge, because HTTP requests are stateless, so the solution I came up with is to send everyone a session ID. (session id), to put it bluntly, it is a random string. Everyone receives it differently. Every time you send an HTTP request to me, send this string along with it so that I can distinguish it. Who is who?
3. Everyone is very happy, but the server is not happy. Everyone only needs to save their own session id, and the server needs to save everyone’s session id! If there are too many access servers, there will be thousands or even hundreds of thousands.
This is a huge overhead for the server and severely limits the server's expansion capabilities. For example, if I use two machines to form a cluster, and Xiao F logs in to the system through machine A, the session id will be saved. On machine A, what if Little F’s next request is forwarded to machine B? Machine B does not have the session id of little F.
Sometimes a little trick is used: session sticky, which means that Xiao F's request is always stuck on machine A, but this doesn't work. If machine A hangs up, it has to be transferred to machine B. .
Then we have to copy the session. Moving the session id between the two machines is almost exhausting.
Later, someone called Memcached came up with a trick: centrally store session IDs in one place, and all machines will access the data in this place. In this way, There is no need to copy, but it increases the possibility of a single point of failure. If the machine responsible for the session hangs up, everyone will have to log in again, and they will probably be scolded to death.
I also tried to put this single machine into a cluster to increase reliability, but no matter what, this small session is a heavy burden for me. .
4. So some people have been thinking, why should I save this abominable session? How good would it be to just let each client save it?
But if these session ids are not saved, how can I verify that the session id sent to me by the client is indeed generated by me? If we don't verify, we don't know whether they are legitimate logged-in users, and those with bad intentions can forge session IDs and do whatever they want.
Well, by the way, the key point is verification!
For example, Little F has logged in to the system, and I will send him a token, which contains Little F’s user id. The next time Little F requests access to me through HTTP again, I will send him a token. This token can be brought over through Http header.
But there is no essential difference between this and session ID. Anyone can forge it, so I have to think of some way to prevent others from forging it.
Then make a signature on the data. For example, I use the HMAC-SHA256 algorithm, add a key that only I know, make a signature on the data, and use this signature and the data as a token. Since others do not know the key, the token cannot be forged.
Related recommendations: "Python Video Tutorial"
I won’t save this token. When Xiao F sends me this token When I come over, I use the same HMAC-SHA256 algorithm and the same key to calculate the signature again on the data, and compare it with the signature in the token. If they are the same, I know that Xiao F has logged in and can I directly get the user ID of little F. If it is not the same, the data part must have been tampered with. I will tell the sender: Sorry, there is no authentication.
#The data in Token is saved in clear text (although I will use Base64 for encoding, but that is not encryption), it can still be seen by others, so I can't. Save sensitive information like passwords in it.
Of course, if a person's token is stolen by someone else, there is nothing I can do about it. I will also think that the thief is a legitimate user. This is actually the same as a person's session id being stolen by others.
In this way, I don’t save the session id. I just generate the token and then verify the token. I use my CPU computing time to obtain my session storage space!
The burden of session ID has been relieved. It can be said that I have nothing to do. My machine cluster can now easily expand horizontally. As the number of user visits increases, I can just add machines directly. This stateless feeling is so good!
Cookie
Cookie is a very specific thing. It refers to a kind of data that can be stored permanently in the browser. It is just a kind of data implemented by the browser. storage function.
The cookie is generated by the server and sent to the browser. The browser saves the cookie in kv form to a text file in a certain directory. The cookie will be sent to the server the next time the same website is requested. Since cookies are stored on the client, the browser has added some restrictions to ensure that cookies will not be used maliciously and will not occupy too much disk space, so the number of cookies for each domain is limited.
Session
session Literally, it is a session. This is similar to when you are talking to someone. How do you know that the person you are talking to is Zhang San and not Li Si? The other party must have certain characteristics (such as appearance) that indicate that he is Zhang San.
session is similar. The server needs to know who is currently sending the request to itself. In order to make this distinction, the server assigns a different "identity identifier" to each client. Then every time the client sends a request to the server, it brings this "identity identifier", and the server knows that the request comes from Who. As for how the client saves this "identity", there are many ways. For browser clients, everyone uses cookies by default.
The server uses session to temporarily save the user's information on the server. The session will be destroyed after the user leaves the website. This method of storing user information is more secure than cookies, but the session has a flaw: if the web server is load balanced, the session will be lost when the next operation request goes to another server.
Token
Token-based authentication can be seen everywhere in the Web field. In most Internet companies using Web API, tokens are the best way to handle authentication for multiple users.
The following features will allow you to use Token-based authentication in your program:
(1) Stateless and extensible
(2) Support mobile devices
(3) Cross-program call
(4) Security
Those big guys who use Token-based authentication, most of the APIs and Web applications you have seen All use tokens. For example Facebook, Twitter, Google, GitHub, etc.
The Origin of Token
Before introducing the principles and advantages of Token-based authentication, you might as well take a look at how previous authentication was done.
Server-based verification
We all know that the HTTP protocol is stateless. This statelessness means that the program needs to verify each request to identify the client's identity.
Before this, the program identified the request through the login information stored on the server. This method is generally accomplished by storing Session.
With the rise of the Web, applications, and mobile terminals, this verification method has gradually exposed problems. Especially when it comes to scalability.
Some issues exposed based on server authentication methods
(1) Session: Each time an authenticated user initiates a request, the server needs to create a record to store information. When more and more users send requests, the memory overhead will continue to increase.
(2) Scalability: Using Session to store login information in the memory of the server comes with scalability issues.
(3) CORS (Cross-Origin Resource Sharing): When we need to use data across multiple mobile devices, the sharing of cross-domain resources can be a headache. When using Ajax to crawl resources from another domain, requests may be blocked.
(4) CSRF (cross-site request forgery): When users visit bank websites, they are vulnerable to cross-site request forgery attacks and can be exploited to access other websites.
Among these issues, scalability is the most prominent. Therefore, we need to find a more effective method.
Token-based authentication principle
Token-based authentication is stateless, and we do not store user information in the server or Session.
This concept solves many problems when storing information on the server side:
NoSession means that your program can add or remove machines as needed without worrying about whether the user is logged in.
The process of Token-based authentication is as follows:
(1) The user sends a request through user name and password.
(2) Program verification.
(3) The program returns a signed token to the client.
(4) The client stores the token and uses it for each request.
(5) The server verifies the token and returns data.
Every request requires a token. The token should be sent in the HTTP header to ensure that HTTP requests are stateless. We also set the server property Access-Control-Allow-Origin:* to allow the server to accept requests from all domains.
It should be noted that when the ACAO header is marked (designating) *, certificates such as HTTP authentication, client SSL certificate and cookies must not be included.
Implementation ideas:
(1) User login verification. After successful verification, the Token is returned to the client.
(2) The client saves the data on the client after receiving it.
(3) The client carries the Token to the server every time it accesses the API.
(4) The server side uses filter filter verification. If the verification is successful, the request data will be returned, if the verification fails, an error code will be returned. After we authenticate the information in the program and obtain the token, we can do many things with this token. We can even create a permission-based token and pass it to third-party applications, which can obtain our data (only with the specific token we allow).
Advantages of Tokens
Stateless and scalable
Tokens stored on the client side It is stateless and can be extended. Based on this statelessness and no storage of session information, the load balancer can transfer user information from one service to other servers.
If we save the authenticated user's information in Session, each request requires the user to send authentication information to the authenticated server (called Session affinity). When the number of users is large, it may cause some congestion.
But don’t rush. After using tokens, these problems are easily solved, because tokens themselves hold the user's verification information.
Security
Sending a token in the request instead of a cookie can prevent CSRF (cross-site request forgery). Even if a cookie is used to store tokens on the client, the cookie is only a storage mechanism and not used for authentication. Not storing information in Session allows us to operate less sessions.
Token is time-limited, and users need to re-verify after a period of time. We do not necessarily need to wait until the token automatically expires. The token has a withdrawal operation. Through token revocacitation, a specific token or a group of tokens with the same authentication can be invalidated.
Extensibility
Tokens enable the creation of programs that share permissions with other programs. For example, you can connect a random social account with your own account (Fackbook or Twitter). When logging into Twitter through the service (we will Buffer this process), we can attach these Buffers to the Twitter data stream (we are allowing Buffer to post to our Twitter stream).
When using tokens, optional permissions can be provided to third-party applications. When users want another application to access their data, we can derive special permission tokens by building our own API.
Multi-platform cross-domain
Let’s talk about CORS (cross-domain resource sharing) in advance. When expanding applications and services, we need to intervene in various Various devices and applications.
Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.
As long as the user has a verified token, data and resources can be requested on any domain.
Access-Control-Allow-Origin: *
When creating a token based on standards, you can set some options. We will describe it in more detail in subsequent articles, but the standard usage will be reflected in JSON Web Tokens.
The latest programs and documentation are provided for JSON Web Tokens. It supports numerous languages. This means you can actually switch your authentication mechanism in the future.
The above is the detailed content of A thorough understanding of cookies, sessions, and tokens in one article. For more information, please follow other related articles on the PHP Chinese website!
![修复:谷歌浏览器请求太多错误 429 [已解决]](https://img.php.cn/upload/article/000/887/227/168160812385289.png)
近期很多Windows用户反映,当他们尝试访问某个URL时,PC上的GoogleChrome浏览器显示错误429。这是因为每次用户尝试在短时间内通过浏览器。通常,此错误是由网站生成的,以避免通过向服务器发送过多请求而被机器人或黑客入侵病毒。用户对在这个阶段可以做什么感到困惑,并因此感到失望。导致此错误的因素可能很多,我们在下面列出了其中一些因素。缓存内存和其他站点数据未清除从第三方来源安装的扩展系统上的一些有害软件病毒攻击在研究了上面列出的因素之后,我们在这篇文章中收集了一些修复程序,这

如果您在Windows10或11PC上遇到语法问题,本文将帮助您解决此问题。Grammarly是最流行的打字助手之一,用于修复语法、拼写、清晰度等。它已经成为写作专业人士必不可少的一部分。但是,如果它不能正常工作,它可能是一个非常令人沮丧的体验。许多Windows用户报告说此工具在他们的计算机上运行不佳。我们做了深入的分析,找到了这个问题的原因和解决方案。为什么Grammarly无法在我的PC上运行?由于几个常见原因,PC上的Grammarly可能无法正常工作。它包括以下内

许多Windows用户最近在尝试访问GoogleChrome浏览器中的网站URL时遇到了一个不寻常的错误,称为Roblox403禁止错误。即使在多次重新启动Chrome应用程序后,他们也无能为力。此错误可能有几个潜在原因,我们在下面概述并列出了其中一些。Chrome的浏览历史和其他缓存以及损坏的数据不稳定的互联网连接网站网址不正确从第三方来源安装的扩展在考虑了上述所有方面之后,我们提出了一些修复程序,可以帮助用户解决此问题。如果您遇到同样的问题,请查看本文中的解决方案。修复1

前言cookie使用最多的地方想必是保存用户的账号与密码,可以避免用户每次登录时都要重新输入1.vue中cookie的安装在终端中输入命令npminstallvue-cookies--save,即可安装cookies,安装之后在main.js文件中写下以下代码import{createApp}from'vue'importVueCookiesfrom'vue-cookies'constapp=createApp(App)app.co

每个网站都通过创建cookie使用户更容易浏览他们的网页和浏览他们的网站。然而,网站创建了一些第三方cookie,使他们能够跟踪访问其他网站的用户,以便更好地了解他们,从而有助于展示广告和其他帖子。一些用户可能认为他们的数据遭到破坏或存在安全风险,而另一些用户可能认为允许这些第三方cookie跟踪他们以在浏览器上获取更多内容是很好的。所以我们在这篇文章中解释了如何在谷歌浏览器中启用或禁用第三方cookies,详细步骤如下。如何在GoogleChrome中启用第三方Cookie如果您认为要

在互联网应用开发中,使用Cookie是常见的一种方式来维护用户会话状态。在PHP语言中,处理Cookie的相关功能在语言的核心库中得到了完善的支持,在最新的PHP8.0版本中,Cookie库得到了进一步的增强。一、PHP中的CookieCookie是一个小文本文件,可以存储在用户的浏览器中,它通常被用来记录用户的个性化设置、登录状态等信息。Cookie是基

php curl设置cookie的方法:1、创建PHP示例文件;2、通过“curl_setopt”函数设置cURL传输选项;3、在CURL中传递cookie即可。

随着互联网技术的不断发展,越来越多的网站需要用户登录才能使用其功能。但是每次用户访问时都需要输入账号密码显然很不方便,因此“记住我”的功能应运而生。本文将介绍如何在ThinkPHP6中采用Cookie技术实现记住我功能。一、Cookie简介Cookie是一种服务器向客户端发送的小文件,在用户访问网站时存储在用户的计算机上。这些文件包含与用户相关的信息,如登录


Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

AI Hentai Generator
Generate AI Hentai for free.

Hot Article

Hot Tools

SublimeText3 Mac version
God-level code editing software (SublimeText3)

SublimeText3 Linux new version
SublimeText3 Linux latest version

SecLists
SecLists is the ultimate security tester's companion. It is a collection of various types of lists that are frequently used during security assessments, all in one place. SecLists helps make security testing more efficient and productive by conveniently providing all the lists a security tester might need. List types include usernames, passwords, URLs, fuzzing payloads, sensitive data patterns, web shells, and more. The tester can simply pull this repository onto a new test machine and he will have access to every type of list he needs.

WebStorm Mac version
Useful JavaScript development tools

SublimeText3 English version
Recommended: Win version, supports code prompts!
