1. Thoughts on cookie technology
A multi-user browser initiated three requests to put a certain product into the shopping cart. A once selected a basketball; B twice, the first selected football and the second selected a pen. How to confirm who the request to select a basketball, football, or pen belongs to? Without confirmation of who it belongs to, the request will be meaningless.
If each request carries a user ID, such as a username, then the server will know who the request belongs to, who the requested product belongs to, and how to record it. So the cookie was born, turning the stateless http service into a stateful http service.
1. Does adding to the shopping cart require verification of password or login status?
Let's look at the unnecessary situation first, because usernames are easy to obtain. If someone else obtains your username, they can also add things to your shopping cart, which is very unsafe. Therefore, it is necessary to verify the password or verify the login status.
Password verification is required. If you use a password verification scheme, you need to carry the password in the cookie, which is very unsafe, and you must verify whether the password is correct every time you request it, which will reduce processing efficiency. How about choosing another solution to verify the login status?
2. How to ensure the uniqueness of the login status.
When a customer logs in, we can store the customer's login status, such as user name and expiration time, in the server's memory or file, but it is also unsafe to only store these, because other users can easily obtain your user name (because Users are regular), so it is necessary to ensure the uniqueness of the login status, so seesion was born.
2. Thoughts on session technology
When a customer logs in, the server will generate a session, which has a globally unique sessionid, and the sessionid will store the customer's relevant information, login status, and expiration time, and will set the sessionid in the cookie and return to the client. In this way, the client will bring the sessionid every time he initiates a request. This sessionid can make the http service stateful, and ensures uniqueness and login status. The sessionid is difficult to obtain by other users.
From the above, it can be seen that the session mechanism relies on cookies. If cookies are disabled, most of the role of session will be lost. Although the sessionid can be placed in the header of the request, this will be inconvenient.
sessionid in java server JSESSIONID=xxxxxxxxxxxx
PHPSESSIONID=xxxxxxxxxxxxxxxxxxxxxx in PHP server
3. The difference between the two
1. Storage location
The cookie is stored on the client side, with a maximum size of 4kb. The password-free login of the website is to store the password in the cookie;
the session is stored on the server side, the size is not limited, and the scope can be shared;
2. Size limit
There is a limit to the cookie size, with a maximum of 4kb;
there is no limit to the session size;
3. Scope
Due to the browser's same-origin policy, cookies will only be sent if they are from the same origin;
sessions can theoretically be shared across multiple domains on the server side.
Generally speaking, cookies and sessions complement each other. They are two parts of http server authentication and two parts of the same technology. There is no difference between the two.
4. Session restrictions
When there are more and more users, there will be more and more seesion, which will increase the burden on the server and have low scalability. In the microservice architecture, because the seesion only exists on one server, how to ensure that all services can be accessed? What about the session?
1. Session copy
2. Session adhesion
After the session is generated on machine A, all subsequent requests will go to machine A.
3. seesion sharing
Seesion can be stored in redis so that all services can access it.