What are the general practices? If it is saved in localstorage, what specific information is saved?
漂亮男人2017-05-19 10:27:57
Storing the token does not actually store the login status, but the token for calling the interface. As long as the token exists and has not expired, it is considered to be still in the login state.
巴扎黑2017-05-19 10:27:57
Token is used for user login check. It is just an ID, and the specific content is on the server side.
我想大声告诉你2017-05-19 10:27:57
There is actually no so-called "status" in the login status. Because http itself is stateless. Therefore, every time the client initiates a request to the server, the server must authenticate.
First time: The user provides username and password authentication, and the server authenticates the user through "username + password". After passing, the server will generate an authentication ID. The server will save this authentication ID and respond to the client with the authentication ID. The client will also save this authentication ID.
The second to the nth time: The client uses the saved authentication identification to initiate a request to the server on behalf of the user, and the server authenticates the user through the "authentication identification".
As for whether the authentication identification is stored in the client's cookie or in local storage, and whether to use the session mechanism or a custom token mechanism. It's just a specific implementation plan.
If you are using a browser, usually cookie+session. If it is an interface, such as an app, a token mechanism is usually customized.
Why do you do this? Because every request requires users to enter their username and password, users will go crazy.
So the client agent (browser), replaces the user. The authentication ID replaces the username and password.
Various technical implementation solutions are nothing more than safety and efficiency considerations
Essentially, it is no different from the user entering their username and password every time