登录的token和session

登录

我们知道,HTTP 是无状态的。也就是说,HTTP 请求方和响应方间无法维护状态,都是一次性的,单一的,它不知道上一次请求都发生了什么。在开发中,一个应用避免不了登录。在登录中我们常用到的就是 tokensession 鉴别。下面我们简单了解一下,更加理解这里面的细节。

服务端 session

session 又叫服务端的 cookie。广义上来看就是保存在了服务端。而 cookie 是在用户端来保存的。

流程:

  1. 浏览器发送账号密码,服务端查询校验

  2. 服务端保存用户登录状态, 即 session。 发送一个对应 sessionid, 即 sessionId

  3. 通过登录接口返回,把 sessionId 种到 cookie

  4. 此后 sessionId 随着 cookie。进行携带, 并比较。

因为由服务端保存,这就又带来了一些问题。

  • 需要维持很多用户,服务器是有压力的

  • 服务端并不在只有一台服务器,如何在多台服务器之间进行共享状态

第一个问题的解决就下面的 token ,就是解决方法。第二个问题:

  1. session 集中存储。如果我们用独立的 Redis 或普通数据库,就可以把 session 都存到一个数据库里。这样就能共享了。

  2. 让相同 IP 的请求在负载均衡时都打到同一台机器上。以 nginx 为例,可以配置 ip_hash 来实现。但这种方式就违背了负载均衡。 而 nginx 负载均衡的特性。是它的一大特色,也是受欢迎的原因之一。

用户端 token

为了解决上面提到的第一个问题。采用 token 是一种方式。由原来的 服务端保存转为了用户端保存。减小了服务器压力。

流程:

  1. 用户登录,服务端校验账号密码,获得用户信息

  2. 把用户信息、token 返回给用户浏览器

  3. 用户端进行管理保存,此后进行携带 token

这里由用户端进行保存,方式就有很多了, cookie , localstroage, sessionStroage

延展一下:token 里通常包含 Access TokenRefresh Token。业务接口用来鉴权使用 Access token。越是权限敏感的业务,我们越希望 Access token 有效期足够短,以避免被盗用。但这又不够友好,所以,使用 Refresh token, 来专门生成 Access Token。它的有效期长一些,在 Access Token 失效之后,用户端拿着 Refresh Token 去请求服务端生成一个新的 Access Token。 但如果两个 token 均失效,则需要重新去登录了。

看到最后了 欢迎访问我的 blog , 里面有你想要的面试信息学习指引 大厂招聘信息。同时你有什么好的信息,可以给我 pr

分类:
前端
标签: