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

momo707577045

基本概念及区分

单点登录 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 的时候,需要重写该项的所有属性(即使未发生变化,也要写上去),否则将识别为独立的两项。不能成功清除会话标识。
      • 如果未成功清除,那应该是属性项未写全。
阅读 1k

原创小文章
专注中小团队开发。 前端技术,效率工具分享与探讨。

[链接]

1.9k 声望
201 粉丝
0 条评论
你知道吗?

[链接]

1.9k 声望
201 粉丝
宣传栏