【达生科技】会话机制及其架构设计探讨

时间 2020-06-04

标签达生科技会话机制及其架构设计探讨栏目系统架构繁體版

原文原文链接

基本概念及区分

单点登陆 SSO（Single Sign On）

在一个多系统共存的环境下，用户在一处登陆后，就不用在其余系统中登陆，也就是用户的一次登陆能获得其余全部系统的信任。
单点登陆在大型网站里使用得很是频繁，例如像阿里巴巴这样的网站，在网站的背后是成百上千的子系统，

惟一登录

也叫「单用户登陆」，是指一个帐号同时只能在一个设备上登陆使用。
经常使用于会员系统网站，如会员视频网站。不能够多人同时使用一个帐号登陆使用。

http 是无状态的协议

每一个 http 请求之间都相互不认识，若是不作程序上的处理，没法区分两个 http 请求是否来至于同一个用户。

会话

浏览器与服务器能够相互识别的对话的过程，
因为 http 是无状态的协议，在不作程序上的处理状况下，每一个 http 请求都是独立的会话。

会话保持

为了解决 http 无状态致使的会话时间过短问题。提出的解决方法，即想办法在不一样的 http 请求中能识别是否来至于同一我的。
一次会话保持：从浏览器访问该域名下的页面开始，到浏览器关闭该域名下的全部页面结束。标识为一个会话。（不用在乎「一次会话」这个名字，笔者以为这个名字起得并很差。名词意义并不等于实际意思，就像「单点登陆」同样，误导人）
时间段会话保持：即以特定时间段内做为一个会话。能够是相对最后一次使用的时间，也能够是绝对时间。

会话保持机制

即实现「会话保持」的具体方案，具体有多种方案，如 cookie 会话机制，session 会话机制，jwt 会话机制等。

cookie

一种技术，每次发送请求都会携带该数据，有本身的实体，原子性的，不可分割的。

cookie 会话机制

是会话保持机制的一种具体实现方案，cookie 的一种应用。
指明了使用的技术就是 cookie

sessionStorage

至关于前端的数据库，数据在「一次会话保持」内有效。
一种技术，前端数据存储的一种技术，有本身的实体。

session 会话机制

是会话保持机制的一种具体实现方案，须要使用「客户端标识」及「服务端存储」
未指明具体使用那些技术。只介绍告终构。

session

本来只是「会话」对应的英文名，不存在实体，也不是一种应用。
在前端中，前端
- session 存储空间的意义，变成了「sessionStorage」的简称，「数据存到 session 中」意味着「数据存到 sessionStorage 中」。
- session 时间范围的意义，变成了「一次会话保持」的时间段。从浏览器访问到浏览器结束。
在后端中mysql
- session 存储空间的意义，变成了「session 会话机制」中的「服务端存储」。存在session，意味着存在「服务端存储」中(多是内存，也多是数据库)
- session 时间范围的意义，变成了「会话保持」的时间段，多是「一次会话保持」时间段，也多是「时间段会话保持」，看具体配置。但更常见的是「时间段会话保持」的时间范围。

会话保持机制具体方案介绍

cookie 会话机制

经常使用数据直接保存在【客户端】web
- 经常使用数据，即在编程中常常用到的数据，如当前用户的 userId，userName等。
特色redis
- 数据可见。
- 每次请求都自动携带上。
- 后端拿到数据后直接使用，无需转换。
- 数据能够直接伪造。利用 Node 伪造一个 http 请求，并修改 cookie 的内容。修改权限什么的。
安全性算法
- csrf（跨域伪造请求攻击），登陆 A 网站，访问 B 网站（B 网站私自调用 A 网站接口，自动带上了cookie，执行了操做）sql
  - 服务端校验请求头 Referer（指明当前流量的来源参考页面），即当前页面的 URL，从而校验域名。
- 可能有 xss （跨站脚本漏洞），往你的网站中注入 js 代码。chrome
  - 经过设置 HttpOnly=true，禁止 JS 获取或操做 cookie 解决
问题数据库
- 每次请求都携带，浪费带宽。
- 容量小
- 数据可见
- 数据不安全，能够被篡改。伪造请求。

session 会话机制

经常使用数据保存在【服务端】，标识符保存在【客户端】编程
- 当前用户的 userId，userName等经常使用数据保存在服务端
- 每一个用户对应一个随机字符串（即与信息无关的标识符），该字符串保存在【客户端】
- 每次通信，客户端传递「标识符」，服务端经过「标识符」找到「经常使用数据」
- 「经常使用数据」和「标识符」分别怎么保存json
  - 「经常使用数据」的客户端存储介质：内存变量，redis（缓存数据库），mysql（常驻数据库）
  - 「标识符」默认是 cookie，也能够经过前端配合，存储在 localStorage 中。若是将数据存储在一个叫 token 的响应头中，就变成了咱们熟悉的 token 校验。但实际上 token 并非解决方案，这只是变量名。不能说是 token 解决方案。
特色
- 数据对外不可见
- 每次接口请求，都须要经历一次从「标识符」到「经常使用数据」的查询
- 不利于扩容和单点登陆。须要在多个服务进程间同步「经常使用数据」
安全性
- csrf（跨域伪造请求攻击）
  - localStorage 不存在，使用 cookie 可杜绝，
- 可能有 xss （跨站脚本漏洞），往你的网站中注入 js 代码。
  - 使用 localStorage 不可杜绝，cookie 可杜绝
问题
- 不利于扩容，数据须要在多进程间同步。
- 使用内存存储，当数据量实在太大时，容量溢出。
- 使用数据库存储，每次查询都消耗 IO，响应速度慢。

JWT(json web token) 会话机制

经常使用数据保存在【客户端】
- JWT 是一个数据结构，不像 cookie 是一种技术，数据能够保存在 cookie 中，也能够 localStorage 中。
组成
- 协议
- 内容体，规定为 json 形式
- 前二者加上秘钥的 hash 值，防止伪造
特色
- 数据可见，但不可伪造。
- 后端拿到数据后直接使用，无需 IO 查询
- 秘钥很重要，泄露了就能够伪造全部人。
- 易于扩容，单点登陆，只需查数据有没有被篡改过就行。
安全性
- csrf（跨域伪造请求攻击）
  - localStorage 不存在，使用 cookie 可杜绝，
- 可能有 xss （跨站脚本漏洞），往你的网站中注入 js 代码。
  - 使用 localStorage 不可杜绝，cookie 可杜绝
问题
- 数据可见

会话保持机制的缺点及定位

仅靠会话保持机制没法解决如下问题

惟一登陆问题

A B 使用同一个帐号。A 登陆，有了 sessionIdA。B 再登陆，有 sessionIdB。
在不作额外判断的情形下，实现不了使 sessionIdA 失效的功能。
只能将 sessionId 存储在数据库中，每次操做时，都查询 sessionId 的有效性。

权限校验问题

当 A 登陆，有了 sessionIdA 后。修改 A 用户的权限，甚至删除 A 用户。
这时 sessionIdA 依然有效。没法限制其使用。
当前流行的后端框架都没有操做特定 session 的功能，只能操做当前 session。
只能每次都查数据库。但既然每次都查数据库，是否是也意味着，将数据存在 session 中没有意义？反正都是查数据库，我直接从数据库拿就好。

会话保持机制的定位

会话数据：数据可丢失，无需复现，两会话的数据差别不会产生冲突。
数据库长期数据：可溯源，可重现，有惟一性。
应该只保存与用户信息无关的数据，如「提交临时表单」等，不须要固话到数据库的临时数据。
由于会话只是记录当前通信的信息，同一个帐号，可能同时有多个会话。若是将用户相关信息长期数据存储在会话中，则可能会致使各个会话间的数据不统一。

会话保持机制及数据缓存架构设计

会话保存层
- 保存 userId，设置终端设备信息，系统类别等固化信息
- userId 不会被改变
- 终端设备信息，如 useragent，用于记录浏览器类型等数据采集
- 系统识别号，譬如「后台管理系统」和「移动端应用」，「移动端应用」的 session 不该该能操做「后台管理系统」。譬如我复制 sessionId，调用「后台管理系统」
redis 数据缓存层，
- 经过 userId 组织数据。实现多个 session 的用户数据同步问题。
- 用户权限，校验每一个接口的调用权限，经过。
- 最后登陆的 sessionId，实现「惟一登陆」。
- 开发经常使用数据。
mysql 数据层
- 固化数据，当对 mysql 数据进行修改时，如修改权限，须要将数据同步到 redis 中。
- 当用户登陆时，生成 redis 的 userId 与 session 映射关系数据。
- mysql 和 redis 的用户数据是同步，同样的。redis 的存在只是为了对特定数据进行优化查询。如每一个接口都要校验的用户权限。

会话保持机制的选择

cookie 会话保持机制
- 自己不带加密功能，容易被伪造。不建议。
session 会话保持机制
- 从 sessionId 到 session 信息。须要通过一次隐射查询。
jwt 会话保持机制
- 多了一次 hash 算法校验，但计算耗时对 IO 耗时来讲不值一提。
- 数据可见，但数据不敏感，影响不大。
- 对比 session，减小一次查询。
- 但因为数据存贮在客户端，每次调接口，都须要传输，虽然量少，但仍是会浪费带宽。
因此最后在 session 与 jwt 中作对比
- 牺牲查询，仍是牺牲带宽
- 笔者倾向于后者。应为带宽的影响是分布在每一个用户上的，不会产生累计效应，不影响服务器速度。
- 而前者的压力彻底集中在服务器中，用户基数大时，对服务器的影响不可忽略。

客户端主动解除会话

据上述会话保持机制可知，保持会话，须要先后两端共同支持（cookie是浏览器默认支持）。故双方都可主动放弃维持该会话

保存在 localStorage
- 直接调用 localStorage.removeItem('key') 便可清除会话标识。从新登陆。
保存在 cookie
- 特殊状况，若后端响应头设置 HttpOnly=true，禁止 JS 获取或操做 cookie 解决。
  - 则前端没法经过代码操做 cookie，没法经过程序清除登陆状态。
  - 但在开发中，可经过客户端主动清除。如使用 chrome 浏览器，调起控制台清除 cookie。
- 若未设置 HttpOnly=true，则可经过 JS 清除 cookie。
```
function setCookie(name, value) {
  var exp = new Date();
  exp.setTime(exp.getTime() - 1);
  document.cookie = name + "=" + escape(value) + `;expires=${exp.toGMTString()};path=/`;
}

setCookie('PHPSESSID', '')
```
  - JS 没有相似 removeItem，同样的 cookie.removeItem 函数。只可经过设置 cookie 的过时时间，让客户端主动帮你清除。
  - 须要注意的是，在重写某项 cookie 的时候，须要重写该项的全部属性（即便未发生变化，也要写上去），不然将识别为独立的两项。不能成功清除会话标识。
  - 若是未成功清除，那应该是属性项未写全。