好像你的描述都不怎么准确.
首先 token, 看你的描述,应该不是 jwt 这种 token,jwt 这种 token ,后端生成后加密返回前端,前端只要带回 token,后端能正常解密,如果 token 中记录了一些特征的话,再对比下特征就可以了.你这个 token 更倾向于比较早期的方式,后端验证登录成功之后,就会把用户的一些信息,一些特征,加个盐,生成个签名,发给前端,前端每次请求,后端根据用户cookie 中的用户 id 到数数据库/缓存/session 中拿到用户信息,特征,重新生成签名对比下,通过就 ok 了.
token 的方案记住我的实现 ,jwt,jwt规范中,payload 中有一个字段 exp
用于记录这个 token 的过期时间,所以,正常的 实现 jwt 的 sdk 内部校验时,会自动对比这个时间,过期延签就会失败.不设置的话,就不验证,不过期. 传统的 token 实现,直接将 cookie 中token 的过期时间设置为用户设置的记住的时间.为了安全,这个值也会写一个 cookie,然后 签名时会把这个值包含在签名验签中.
sessionid 你说的这个也不是特别清楚,我能看到用 sessionid 的地方,大多都不是为了做记住我,而是为了做登录,直接使用 sessionid 的一般都是浏览器关闭即结束会话.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…