我们公司准备用前后端分离做项目, 前后端为了保持登录状态, 我看了网上很多都说的用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 中要注意验证合法性。
本质上前端对数据进行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 中要注意验证合法性。