3种Web会话管理方式
无状态的HTTP
一次请求结束、链接断开。服务器再收到下一个请求、它就不知道是哪个用户发过来了。但是服务器会知道是从哪个客户端发起的、不过我们管理的是用户、不是客户端。所以就有了会话管理
server端session
过程
- 用户第一次请求 –> 服务器创建session对象(每个session会分配有唯一id，以及设置有失效时间) –> 服务器通过cookie返回sessionid到浏览器
- 用户请求 –> 服务器获取cookie里的sessionid –> 验证session有效 –> 服务器延长失效时间
- session超过失效时间 –> 服务器销毁该session –> 用户请求 –> 服务器创建新session –> 重新登录
- 用户登录成功 –> 服务器往session里设置登录凭证
- 用户请求 –> sessionid通过cookie携带发送到服务器 –> 服务器验证对应session的登录凭证 –> 响应请求
- 用户登出 –> 服务器清除登录凭证
优点
- Java、.net、PHP原生支持，开发简单
- 安全性好。只要sessionid足够随机
缺点
- 多用户同时在线会占据较大内存
- 应用采用集群部署时需要处理多台服务器之间session共享的问题
- 多台服务器之间共享session时，还可能需要处理跨域问题
- 不适合用在native app：不好管理cookie
- 不适合用来做纯API服务的登录认证
解决方法
- 对缺点1和2：可以采用中间服务器管理session
- 对缺点3：前后端解决sessionid的cookie跨域即可
- 实际使用时可以采用单点登录框架
cookie-base
过程
- 用户登录 –> 服务器创建登录凭证、数字签名、对称加密 –> key-value形式写入cookie
- 用户请求 –> 服务器获取cookie、解密、数字签名认证 –> 判断登录凭证有效期 –> 重新登录/响应请求
优点
- 减轻服务端内存压力，只需要创建和验证cookie
- 没有多服务器共享session的问题，只需要登录逻辑、数字签名和密钥文件在服务器之间共享
- 很多web开发平台(比如PHP的yii)或框架默认使用该方式
缺点
- cookie的大小限制
- 依然用了cookie，所以也有跨域问题
- 不适合用在native app：不好管理cookie
- 不适合用来做纯API服务的登录认证
token-base
过程
- (类似cookie-based)用户登录 –> 服务端返回token到客户端
- 用户请求(通过url参数或者http header主动带上token) –> 服务端验证token
优点
- 适用于native app、SPA
缺点
- 仅限于纯API的web应用，不适用于点击链接直接请求的情况
- 可能会有跨域问题，不过很容易解决
- token刷新的问题需要注意
