前言

刚好做到扫码登录的需求,所以顺便复习一下登录。众所周知,http是无状态的,所以每次发送请求的时候,对方都不知道你是谁,这时候就需要借用外力来让服务器知道我是谁。常见的登录方式有两种,一种是session,一种是token

session登录机制

  • 当用户请求登录接口进行登录;
  • 服务端获得登录信息,从而在数据库中查找到了对应的用户信息,并将其生成一个session,可以理解成session里面包含着用户信息,将session存储起来,并用sessionId对应该session,最后将sessionId通过set-Cookie发送给客户端;

netty 判断session是否存活 session判断用户登录_js

  • 客户端收到了接口的“登录成功”的回应,浏览器发现接口响应头中有set-Cookie,自动将cookie保存在本地(可在控制台->network->application中找到该域名下的cookie);

netty 判断session是否存活 session判断用户登录_js_02

  • 客户端又发起了一个请求,此时请求中会自动加入cookie字段,告诉客户端我是某某用户。

netty 判断session是否存活 session判断用户登录_用户信息_03

以上就是登录机制的全过程了。

netty 判断session是否存活 session判断用户登录_服务器_04

可见session有两个特点:即是服务器生成的也是服务器存储的

token登录机制

  • 当用户请求登录接口进行登录;
  • 服务端获得登录信息,使用自定义的key和加密方法对用户信息做了加密生成一个token,并透过接口返回用户;

netty 判断session是否存活 session判断用户登录_用户信息_05

  • 用户在接口返回的内容中获得了token,并存储起来,一般是存储在localStorage中;
  • 用户发送下一个请求时,手动将token放在请求的header中;

netty 判断session是否存活 session判断用户登录_netty 判断session是否存活_06

  • 服务器接收到接口在请求头中获得token,使用自定义的token进行解密,获得用户信息,从而返回相应的数据。

netty 判断session是否存活 session判断用户登录_netty 判断session是否存活_07

token是服务器生成,但是是保存在了客户端中,利用了时间换空间的思想,降低了服务器的存储压力,但是增加了服务器的解密时间

总结

  • session是服务器生成并保存的,服务器通过set-Cookie返回sessionId,客户端通过cookie发送sessionId
  • token是服务器生成,客户端保存,服务器通过接口返回给客户端,客户端保存之后每次发送请求都将token放在header中发送给服务器。