|
|
mgcnrx11
V2EX 第 71403 号会员,加入于 2014-08-20 12:23:59 +08:00今日活跃度排名 9854
|
曾用主题
@import url("//jkjoke.b0.upaiyun.com/css/modern.css");
mgcnrx11 最近回复了
同遇到,没有售后,买新的底座还不通用,底拆掉重新钻孔安装新的底座。最后找咸鱼买回同款。哎...
我发觉,装了行车记录仪。每逢生气上头就把纪录保存下来,同时想着回家就去导出视频举报,那气就能消散不少
在使用 nvm 管理 nodejs 的版本之后,会发现 包管理器 的版本用 corepack 来做管理就会出现问题。在用 nvm 之后,npm 的版本会跟随 nodejs 版本切换而切换,但是 corepack 安装的 pnpm 缺无法自动切换了。
导致的结果是可能会用上了不兼容的 nodejs 和 pnpm 版本。不知道有什么好的实践方式?
能想到的是通过环境变量 COREPACK_HOME 来隔离不同的 corepack 安装路径
在很久很久以前的互联网上,前后端还是不分离的。浏览器显示的网页,都是通过后端的模版技术动态渲染成 HTML ,返回给浏览器的。那时候还没有 Ajax 的流行,浏览器要做的操作,都得一次一次的请求后端,后端返回一个完整的 HTML 页面来显示结果。
在这个背景之下,HTTP 协议又不支持保持会话。那后端怎么知道多个请求之间的联系?例如某个用户先执行操作 A ,然后执行了 B 。所以,需要一种“保持用户状态”的机制,在后端能保存用户的状态使得后端知道用户执行了哪些操作,又能为这些操作保存一些信息。这个就是 Session 会话了。本质上,它是设计出来“保持用户状态”的。
后来,Ajax 使得异步刷新页面,以及后来大前端的流行,各自新的标准和浏览器技术涌现出来。使得我们有更多的方法来做到类似“保持用户状态”的效果。例如,我们可以把用户的状态保存在浏览器端的 Storage 里面。这时候,就会显得后端 Session 来保持用户状态,没有以前那么必要了。当然,也有很多场景会需要在后端保持用户状态。
那么,在不怎么需要后端 Session 来保持用户状态的场景,后端就不需要为用户专门开辟一个区域来存储,它只需要去知道这个请求是否合法的访问就足够了。所以,开始使用了 token 。
所以,session 会在每次访问后,重新刷新 session 的有效期。因为他需要持续保持会话,只要用户一天不离开,会话都需要继续持续下去。某种程度来说,这个有效期时间也可以当成是某个“用户状态”的数据。
另一方面,在使用 token 时,它仅用于判断请求是否合法访问,没有说要用来保持用户状态的。那就很自然的不会去保持用户状态。所以就是一种固定的有效期。不会像会话的场景一样自动延长。也就是只能手动的通过 refresh_token 来延长。
上面说了这么多,都没有提到 cookie 。我理解的是,用不用 cookie 其实都不影响理解 session 和 token 的一些区别。我不能把 token 放在 cookie 吗?我不能把 sessionid 放在 header 用吗?只是没有这个用的习惯而已。