84669 person learning
152542 person learning
20005 person learning
5487 person learning
7821 person learning
359900 person learning
3350 person learning
180660 person learning
48569 person learning
18603 person learning
40936 person learning
1549 person learning
1183 person learning
32909 person learning
我们公司准备用前后端分离做项目, 前后端为了保持登录状态, 我看了网上很多都说的用token来保持登录, 现在我在token中直接存放md5(sessionid)可以么?有没有什么问题?
本质上前端对数据进行encrypt是降低可读性，比如用户的敏感数据，处于隐私保护的目的。假如你传递的是seesion_id的话，是没必要再进行encrypt的。至于上面有人提到的md5这之类的做法是错误的（针对传递seesion_id)，因为本身seesion_id就是作为key来使用，md5属于hash的一种方式（不可逆），后端如果要使用的话也是直接拿来用，你几层md5都没有意义了（如果被劫持了，直接就用了）
你提到的token问题，在于后端如何来实现authentication部分，是恢复session来储存信息，还是使用token来验证接口调用权限。根据后端的实现方式不同而不同。
session是浏览器中放置的cookie来保存，依靠的是浏览器的cookie expire时间来控制登陆保持时间（客户端角度）。
其余的内容你参考下这个session cookie vs token
多加密几层吧，一个md5太简单了。
token你就直接在登陆 时有MD5加密 日期 就好了啊, 然后扔redis, 之后的在拦截器拦一下做个判断就好了
只要不存放敏感的内容（密码等），个人没有问题的。建议使用现在流行的 jwt，各种语言都有实现的库，使用起来还是非常的方便的。
session id就是一个token，再md5反而多余。
sessionid 本身难道不就是一个加密后明文的 token 么…对它再 md5 没必要啊
sessionid
完全可以，用jwt吧。在token 中要注意验证合法性。
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
本质上前端对数据进行encrypt是降低可读性，比如用户的敏感数据，处于隐私保护的目的。假如你传递的是seesion_id的话，是没必要再进行encrypt的。至于上面有人提到的md5这之类的做法是错误的（针对传递seesion_id)，因为本身seesion_id就是作为key来使用，md5属于hash的一种方式（不可逆），后端如果要使用的话也是直接拿来用，你几层md5都没有意义了（如果被劫持了，直接就用了）
你提到的token问题，在于后端如何来实现authentication部分，是恢复session来储存信息，还是使用token来验证接口调用权限。根据后端的实现方式不同而不同。
session是浏览器中放置的cookie来保存，依靠的是浏览器的cookie expire时间来控制登陆保持时间（客户端角度）。
其余的内容你参考下这个session cookie vs token
多加密几层吧，一个md5太简单了。
token你就直接在登陆 时有MD5加密 日期 就好了啊, 然后扔redis, 之后的在拦截器拦一下做个判断就好了
只要不存放敏感的内容（密码等），个人没有问题的。建议使用现在流行的 jwt，各种语言都有实现的库，使用起来还是非常的方便的。
session id就是一个token，再md5反而多余。
sessionid本身难道不就是一个加密后明文的 token 么…对它再 md5 没必要啊完全可以，用jwt吧。在token 中要注意验证合法性。