Our company is going to use the front-end and back-end separation to do projects. In order to maintain the login status of the front-end and the front-end, I read a lot of people on the Internet saying that tokens are used to maintain login. Now I can directly store the md5 (sessionid) in the token? Is there any? What’s the problem?
ringa_lee2017-05-16 13:00:06
Essentially, the front-end encrypts the data to reduce the readability, such as the user's sensitive data, for the purpose of privacy protection. If you pass the seesion_id, there is no need to encrypt it. As for the md5 method mentioned above, it is wrong (for passing seesion_id), because the seesion_id itself is used as a key, and md5 is a hash method (irreversible). If the backend wants to use it, it can be used directly. Come and use it, your layers of md5 are meaningless (if it is hijacked, just use it directly)
The token issue you mentioned lies in how the backend implements the authentication part, whether to restore the session to store information, or to use the token to verify the interface calling authority. It varies depending on how the backend is implemented.
Session is saved by a cookie placed in the browser, and relies on the browser's cookie expiration time to control the login retention time (client perspective).
For the rest of the content, please refer to this session cookie vs token
習慣沉默2017-05-16 13:00:06
Token, just have the MD5 encrypted date when logging in, then throw it into redis, and then block it in the interceptor to make a judgment
PHP中文网2017-05-16 13:00:06
As long as no sensitive content (passwords, etc.) is stored, there is no problem for me. It is recommended to use the popular jwt. There are libraries implemented in various languages, and it is very convenient to use.
世界只因有你2017-05-16 13:00:06
sessionid Isn’t it an encrypted plaintext token? There is no need to md5 it
给我你的怀抱2017-05-16 13:00:06
It’s absolutely fine, use jwt. Pay attention to verifying the legality of the token.