When the server responds to the client's request, it pushes a Cookie to the client. This Cookie records some information on the server. The client carries this Cookie in the subsequent request, and the server can judge the context of the request according to this Cookie.
The appearance of Cookie is a means to transition from statelessness to nationality.
Taking login as an example, the user enters an account name and password and sends a request to the server. The server generates a Cookie and sends it to the browser. The browser saves cookies in a text file in a directory in the form of k-v, and will send cookies to the server the next time it requests the same website. The server verifies whether the received Cookie is consistent with the Cookie of the server; Otherwise, the verification fails. This is the original idea.
Img src=' (domain name 1) and c.d.e.f.com.cn (domain name 2). Domain name 2 wants to read the Cookie of domain name 1 Domain name 1 What domains can be declared? The answer is e.ffcom.cn or f.com.cn. Browsers cannot accept cookies with domian as. Com.cn, because if the domain name of cookie can be set as suffix, it will be a canyon war.
If you set the domain name 1 with Set-Coo.
kie:mykey = my value 1； domain = e . f . com . cn； Path ='/'
Set-cookie of domain name 2: mykey = myvalue2; domain = e . f . com . cn； Path ='/'
Then the value of mykey in this field will be rewritten as myvalue2. It is easy to understand that the mykey of a Cookie is unique in the same domain. Usually we need to set the correct domain and path to reduce unnecessary data transmission and save bandwidth.
With the rise of interactive Web, the limitation of Cookie size and the limitation of the number of cookies stored by browsers, we must need more powerful space to store a lot of user information, such as who logged into our website and who added goods to the shopping cart. Cookies are obviously not enough for servers to store tens of millions or even more users' information. So what should we do?
Where is the user information stored? Can it exist directly in the server?
If it exists in the server, 1, it is a huge overhead for the server, which seriously limits the expansion ability of the server. 2. Suppose the web server is load-balanced, and the user user 1 logs in the system through machine A. If the next request is forwarded to another machine B, the user information is not stored on machine B, so the sessionId cannot be found, so the sessionId should not be stored on the server. At this time, redis/Memcached came out to solve this problem, which can be simply understood as caching database.
When we store the sessionId in an independent cache server, all machines will access the cache system according to the sessionId to obtain user information and authentication. Then the problem is solved.
According to its working principle, have you found out what kind of problems will appear in this way? That is to increase the possibility of single sign-on failure. If the machine in charge of the session hangs up, the whole login will also hang up. However, generally speaking, in a project, the machine responsible for the session is also a cluster of multiple machines for load balancing, which increases the reliability.
Thinking:
Will the user information be lost if the server is restarted?
Redis and other cache servers also have a cluster. Suppose a service is restarted, user information will be found from other running servers. What if all the servers really crash at once? The general coping strategy is to regularly brush the user information stored in the memory to the host hard disk to persist the data. Even if it is lost, it only loses user data within a few minutes of restarting.
Cookie session restriction
According to different cookies, users can disable cookies on the browser side.
Cross-terminal compatible applications are not supported.
The business system constantly requires the cache server to find user information, which increases the memory overhead and the pressure on the server is too high.
The server is stateful. If there is no way to cache the server, it is very difficult to expand the capacity, and it is necessary to copy sessionId crazily in multiple servers.
There is the possibility of single sign-on failure.
Single sign-on, SSO for short. With the development of enterprises, a large system may contain n subsystems, and users need to log in many times when operating different systems, which is very troublesome. Single sign-on is used to solve this problem. In a multi-user system, you only need to log in once to access other trusted systems.
As we said before, single sign-on is shared with top-level domains based on cookie, which can be divided into the following three types according to different situations.
Under the same site;
The system is under the same top-level domain name;
Each subsystem belongs to a different top-level domain.
Generally speaking, enterprises have top-level domain names. As mentioned above, single sign-on under the same site and top-level domain takes advantage of the characteristics of Cookie top-level domain. I believe everyone understands this process and will not repeat it. But what if it's a different field? Cookie between different domains are not shared. What should I do?
What we want to talk about here is the CAS (Central Certification Service) process, which is the standard process of single sign-on. It is specially used for authentication with the help of an independent system, which is called SSO system in the following.
The process is actually the same as the Cookie session mode. Single sign-on means that each subsystem has a complete Cookie session mode plus a Cookie session SSO system.
When the user accesses system A, he jumps to SSO system when he needs to log in. After passing the account password authentication in the SSO system, the server side of SSO saves the session and generates a sessionId to return to the browser side of SSO. The browser writes the Cookie into the SSO domain, and generates a generated ST, which is sent to the system A, and the system A uses this ST to request the SSO system for verification. After the verification is successful, the server of system A writes the login status into the session and plants Cookie under the system A domain. After that, when system A does login verification, it is authentication in the same domain.
At this time, the user accesses system B, and when he jumps to SSO to log in, he finds that SSO has logged in. Then SSO generates a ST and brings it to system B. System B uses this ST to request SSO system for verification. After the verification is successful, the server of system B writes the login status into the session and sets Cookie under the system B domain. It can be seen that in this process, system B does not need to log in again.
About "I found SSO logged in when I jumped to SSO to log in", how did this happen? This involves the Oauth2 authorization mechanism, so I won't talk about it here. Let's make a simple idea, that is, when system B jumps to SSO system, let it jump from system A, use the session information of system A to jump to SSO, and then return to system B through redirection.
Regarding Oauth2, you can move to Ruan Yifeng's Four Ways of OAuth 2.0.
We have analyzed the limitations of Cookie-session. Is there a more thorough solution? Since the existence of SSO authentication system will increase the possibility of single point failure, should we simply not? This is the idea of decentralization, that is, the cache server for storing and verifying user information is omitted, and the verification is carried out in their respective systems in another way. Simply put, the implementation method is to encrypt all the information of the session into a Cookie and send it to the browser, and exchange the computing power of the cpu for space.
The server does not save the sessionId. After the user logs in to the system, the server issues a token to him. The next time a user requests to access the server through Http, he will carry this token through the Http header or url for verification. In order to prevent others from forging, we can add a key to the data that only we know, make a signature, and send the data together with this signature as a token. So we don't need to save the token, because the token sent to the user already contains the user information. When the user requests it again, I use the same algorithm and key to encrypt the data in this token. If the encryption result is consistent with the signature in the token, then we can authenticate and get the user information from it.
For the server, this is only responsible for generating the token and then verifying the token, so there is no need for an additional cache server to store a large number of sessions. When the number of visits increases, we only need to expand the server with high access demand, which is more economical than expanding the server in the whole user center.
If someone tampered with the user information, but the key is unknown, the signature in the token must be inconsistent with the signature calculated by the tampered client, and the authentication will fail, so there is no need to worry about security issues.
About the timeliness of token, it is like this: the first login generates a token according to the account password, and then every time the server updates the timestamp, it sends a new token, and the client replaces the original token.
Exiting jwt mode is actually a false login failure, because it is just an illusion formed by the browser clearing the token. If you use your previous token, you can still log in successfully as long as it has not expired.
Security depends on the key, once the key is exposed.
The data generated by encryption is relatively long and takes up relatively more traffic.
Does not rely on Cookie, can be used across programs, and supports mobile devices.
Compared with cookie-session mode without single sign-on, it has strong scalability.
The server is stateless and there is no need to store user information in the server or session.
For the mode of single sign-on, which needs to constantly send verification requests to SSO sites, it saves a lot of requests.
Related questions and answers: