Before discussing the cross domain sharing of session, we should first understand what session has done and has not done
- HTTP is stateless, that is to say, the server does not know who has visited it, but sometimes we need to keep this state. For example, if the user logs in every time, the user experience is really bad. Session solves this problem. It maintains the user login information on the server and generates a jsessionid for the customer The client will take this jsession ID with it the next time it visits the server, and the server will search the user information according to this ID. Of course, the disadvantages of session are also obvious. Session exists in the memory of the server. If there are too many sessions, the performance of the server will be affected. Because session is only in one server, when there are multiple servers, accessing other servers will definitely fail.
After making clear what session does and its defects, it is much easier to solve the problems existing in session. Let me briefly talk about five solutions
Session stickysession copy session centralized storage cookietoken
Session sticky: it means that requests from the same client will fall on the same server, because they will not fall on other servers, so cross domain problems will not occur. But the disadvantage of this scheme is very obvious, that is, no matter what algorithm is used, the user will decide which server the user’s request falls on, which may cause a single point of pressure, and if a server has problems, it may cause people in an area to be unable to access
Session replication: refers to the synchronization of session information between servers, that is, all session information is saved on each server. The disadvantages of doing so are also very obvious. As mentioned above, session is stored in memory, which will seriously affect the performance of the server. Of course, you can also store it in the database, but it will greatly affect the response speed. Another disadvantage is that when the traffic is too large, it will cause a lot of network overhead due to the problem of mutual synchronization
Session centralized storage: it refers to the centralized storage of sessions in a third-party server, which can be redis, database or other things. When you need to access it, go to this server. This also has some disadvantages. First of all, it is a single point problem. If the server goes down, all services are unavailable. Therefore, it is necessary to build a cluster here, which will waste server resources. Another point is that every time you verify, you need to check with this server, which will increase the network overhead and reduce the access speed
Cookie: the state information is no longer saved in the server, but in the client. Every time the client visits the server, it brings the information to the server. However, cookies also have many problems. The most concerned problem is security. Because information is stored on the client, it is easy to be stolen and tampered with. Of course, there are solutions to these security problems. This is not the main reason for restricting cookies. The real reason for restricting cookies is that many devices do not support * * cookies
Token: similar to cookie, token is maintained by client, and information is stored in client, which is platform independent. A token is essentially a string given by the server to the client, which contains some authentication information. It is equivalent to an identity token. You can get its service with this token. Compared with cookie, token is more flexible and can be generated anywhere. The permission system based on token is very easy to implement
Of course, the above five solutions are not the only ones. I just listed a few representative ones.
Solutions are used to solve problems. There is no good saying about the above solutions. Only the right one is the best.
- What are the web front end technologies? What are the differences between cookie and session
- JWT and token + redis scheme of spring security
- Some uncommon problems and solutions of cookie
- If the iframe in IE refers to the cross domain site page, the session fails
- Three ways of adding cookie by scratch
- Illegalargumentexception: control character in cookie value or attribute tomcat7
- Illegalargumentexception error when adding cookie to response
- Parsing the exception of storing JSON string in cookie
- HTTP error 401 and 403 detailed explanation and solution
- Solve the problem that the interface between C # WinForm program and Oracle doesn’t respond for a long time
- Shiro deserialization vulnerability replication (cve-2016-4437)
- Windows FTP Error 425: Unable to build data connection
- How to Configure DHCP for Multiple VLANs?
- DHCP principle and experimental verification
- SQL server error 15404 solution
- 0xc0000005: solution to access conflict when writing to location 0x00000000
- There is an unhandled exception at: 0xc0000005: an access conflict occurred while reading location 0x00000000.
- Could not publish server configuration for Tomcat v8.5 server at localhost
- MS SQL Could not obtain information about Windows NT group/user ‘domain\login’, error code 0x5. [SQ…
- [solved] sql30082n security processing failed with reason “24” (“user name and / or password invalid”)