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

基本概念及区分

单点登录 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 时间范围的意义，变成了「一次会话保持」的时间段。从浏览器访问到浏览器结束。

• 在后端中

  • session 存储空间的意义，变成了「session 会话机制」中的「服务端存储」。存在session，意味着存在「服务端存储」中(可能是内存，也可能是数据库)
  • session 时间范围的意义，变成了「会话保持」的时间段，可能是「一次会话保持」时间段，也可能是「时间段会话保持」，看具体配置。但更常见的是「时间段会话保持」的时间范围。

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

cookie 会话机制

• 常用数据直接保存在【客户端】

  • 常用数据，即在编程中经常用到的数据，如当前用户的 userId，userName等。

• 特点

  • 数据可见。
  • 每次请求都自动携带上。
  • 后端拿到数据后直接使用，无需转换。
  • 数据可以直接伪造。利用 Node 伪造一个 http 请求，并修改 cookie 的内容。修改权限什么的。

• 安全性

  • csrf（跨域伪造请求攻击），登录 A 网站，访问 B 网站（B 网站私自调用 A 网站接口，自动带上了cookie，执行了操作）

    • 服务端校验请求头 Referer（指明当前流量的来源参考页面），即当前页面的 URL，从而校验域名。

  • 可能有 xss （跨站脚本漏洞），往你的网站中注入 js 代码。

    • 通过设置 HttpOnly=true，禁止 JS 获取或操作 cookie 解决

• 问题

  • 每次请求都携带，浪费带宽。
  • 容量小
  • 数据可见
  • 数据不安全，可以被篡改。伪造请求。

session 会话机制

• 常用数据保存在【服务端】，标识符保存在【客户端】

  • 当前用户的 userId，userName等常用数据保存在服务端
  • 每个用户对应一个随机字符串（即与信息无关的标识符），该字符串保存在【客户端】
  • 每次通讯，客户端传递「标识符」，服务端通过「标识符」找到「常用数据」

  • 「常用数据」和「标识符」分别怎么保存

    • 「常用数据」的客户端存储介质：内存变量，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 的时候，需要重写该项的所有属性（即使未发生变化，也要写上去），否则将识别为独立的两项。不能成功清除会话标识。
    • 如果未成功清除，那应该是属性项未写全。