笔者因为工作须要，最近对国内外两款出名的电商网站的用户会话治理(User Session Management) 的实现机制做了一些调研，这里把我学习到的一些常识分享给各位同行，心愿起到抛砖引玉的作用。

咱们首先看看大家日常生活中都会应用的某宝网站的用户会话管理机制。

在电脑端拜访某宝网，输出用户名和明码，点击登录：

会察看到一个 HTTP Post 申请，login，发送往后台服务器：

https://login.taobao.com/newl…

该申请的 Form Data 中蕴含 loginId 和 password2 两个字段，别离保护了用户输出的用户名的明文，以及明码进行 RSA 加密后的值。

上面介绍如何自行找到前端将用户输出的登录明码进行 RSA 加密的精确地位。

在 Chrome 开发者工具里找到 login 申请，在 Initiator 面板里找到发动该申请的调用栈。稍有教训的前端开发人员，从 onClick 和 t.loginSubmit 就能推断出，用户名和明码的输入框，实现在一个 Form 表单里，点击登录按钮后，触发表单的 Submit.

关上上图找到的 index.js 文件：

https://x.alicdn.com/vip/hava…
间接搜寻关键字 password2，很快就能找到 RSA 加密的代码地位：

设置断点后，运行时点击登录按钮，断点触发，能够进入 rsaPassword 函数，查看 RSA 加密算法的明细。

这个 index.js 里还能发现一些乏味的货色。比方提供了 rsaPassword 办法的模块外部，还保护了一个反对的国家列表，countryList，外面有 168 个国家和地区：

然而在浏览器端关上某宝网，国家和地区的下拉列表里，只能看到十余条记录。这应该是前台某处依据某种逻辑做了过滤：

此外，咱们在这个电商网站首页左边区域，能看到疾速充值话费的面板，如下图绿色高亮区域所示：

该页面的 HTML 源代码，并不是动态编写于首页的 HTML 文件中，而是通过一个叫做 bianming-phone(“ 便民 ” 的拼音加上 ” 手机 ” 的英文单词 phone) 的 HTTP 申请，从后盾读取到前台，而后再注入到前台页面中：

同理，还有这个旅行视图片段(相当于 SAP UI5 里的 View Fragment)：

读取该视图片段的 HTTP 申请：bianming-trip

看到这里，笔者不由得联想起 SAP Commerce Cloud 前台的 CMS 驱动设计，二者都是从电商页面连贯的后盾零碎读取局部页面配置信息，堪称殊途同归。

• SAP S/4HANA 的 UI 格调是 Fiori UX，实现的前端框架是 SAP UI5；
• SAP Commerce Cloud UI 实现的前端框架是 Angular；
• help.sap.com 采纳 AngulaJS 实现，www.sap.com 应用的是 React.
• 某宝网首页，采纳的是阿里自研的前端框架，Kissy：

咱们在某宝网首页看到目不暇接的商品图片，都是被 Kissy 驱动，通过向 CDN 服务器发动的数据申请而被加载的：

在这些页面片段的源代码里还看到一些有意思的内容，比方这种“上线请删除”的正文。我当初浏览的就是上线后的代码呀，咋还可能看到这些正文 :)

咱们在电商网站上购物时，抉择好了本人心仪的商品，退出购物车之后，当然不心愿点击结帐之后，突然弹出要求从新登录的界面，这岂不是令人败兴。另外，当咱们不小心误操作，点击了浏览器刷新按钮，咱们冀望页面刷新后，依然处于登录状态，之前增加到购物车里的商品不会失落。这些都属于用户会话治理的领域。

某宝网页面的用户会话治理，是通过客户端 Cookie 和服务器端保护的用户会话对象来实现的。
用户胜利登录之后，服务器创立对应的 Session 对象，返回给 login HTTP 申请的响应头部，蕴含了很多 set-cookie 字段：

浏览器解析这些响应，将服务器颁发的 Cookie 设置到本地。下一次用户再次操作电商网站，触发新的发向服务器端的申请时，浏览器会主动将这些 Cookie 字段设置到申请头部。服务器接管到这些 Cookie 字段，就能在内存中定位到之前该用户登录后对应创立的 Session 对象，从而可能辨认出该用户。

这些 Cookie 在 Chrome 开发者工具里也能查看。

• Cookie 的 Expires 字段寄存的是过期工夫，当 Expires 为 Session 时，意为该 Cookie 只在以后会话内无效，浏览器敞开则 Cookie 主动删除。
• 带有 Http Only 的 Cookie，无奈被客户端 JavaScript 代码读取，进步了安全性，防止了 Cookie 通过 XSS 攻打被窃取的可能。
• Secure 为 true 的 Cookie，无奈通过 HTTP 协定传输到服务器，只能通过 HTTPS 发送。

这个电商网站服务器颁发的 Cookie 里，字段 lid 存储的是用户名通过 URL encode 之后的值，dnk 寄存的是用户名的 Unicode：

上面再看另一款来自国外的电商网站，SAP Commerce Cloud 的用户会话管理机制的设计和实现。

SAP Commerce Cloud UI，基于 100% API 驱动的无头电商架构，Commerce 后盾将 Commerce 外围业务通过 OCC(Omni Commerce Connect) API 的形式裸露进去。借助这些 API 和开源的 SAP Spartacus 库，客户能够自行开发具备个性化 UX 的电商网站。

SAP Commerce Cloud 有个名为 Oauth2 的 extension，基于 OAuth 2.0 协定实现了用户认证和令牌颁发 / 性能, 反对 OAuth 2.0 协定定义的包含 Resource Owner Password Flow 在内的全副四种认证流。

SAP Commerce Cloud UI 表演了 OAuth 2.0 认证框架中的客户端 (Client) 角色，通过生产 SAP Commerce Oauth2 扩大提供的 OAuth 系列 API，实现用户会话治理。

让咱们从最初始的用户登录场景说起。
输出用户名和明码：

SAP Commerce Cloud UI 调用 Commerce OAuth2 API，endpoint 为 /authorizationserver/oauth/token, 将用户名，明码，client_id 和 client_secret 去换取拜访令牌 (Access Token) 和刷新令牌(Refresh Token).

这里的 SAP Commerce Cloud UI 作为 OAuth 认证体系里的客户端，其 client_id 和 client_secret 在 Commerce Backoffice 里配置：

服务器端验证通过后，会颁发拜访令牌和刷新令牌，如下图 access_token 和 refresh_token 字段所示：

SAP Commerce Cloud UI 在 OAuth 体系中表演的角色是客户端，通过拜访令牌，取得拜访 Commerce 后盾服务器上的业务数据的许可。而刷新令牌，用于当拜访令牌过期时，由客户端凭借其换取新的拜访令牌。刷新令牌自身是一个凭证，表明持有其的客户端，已经通过 OAuth 认证，取得了拜访受爱护资源的许可，当通过刷新令牌再次申请新的拜访令牌时，客户端不必再从头开始走一遍 OAuth 认证的残缺流程。

SAP Commerce Cloud 的拜访令牌和刷新令牌都有过期工夫，有时也称为 TTL(Time-to-Live，存活工夫)，默认值别离为 12 小时和 30 天。

而咱们团队的开发人员，在开发 SAP Commerce Cloud UI 用户会话治理性能，进行各种边界条件的测试时，为了不便起见，通常将本人本地搭建的 Commerce 服务器上令牌的过期工夫进行了调整。比方下图的例子，二者别离调整为 30 秒和 60 秒之后过期：

拜访令牌获取之后，在接下来 Commerce Cloud UI 生产后盾 OCC API 时，会将其附加在 HTTP 申请的头部字段里：

如果此时拜访令牌曾经过期，则该申请会收到服务器 401 谬误的应答：

以及谬误详情 InvalidTokenError:Access token expired: IqQ-8cYzHV1gjQOpnYytHTFPt30

显然这种偏技术的谬误音讯不应该显示给用户，侥幸的是咱们还有刷新令牌。此时，SAP Commerce Cloud UI 会将过期的拜访令牌，连同刷新令牌一齐发送给 Commerce 后盾，申请一个新的拜访令牌：

SAP Commerce Cloud UI 首次登录申请令牌时，grant_type 的值为 password；而拜访令牌过期，应用刷新令牌从新申请时，grant_type 的值应该填充为 refresh_token.

如果刷新令牌的过期工夫也达到了，该怎么办？没有刷新令牌，也就无从获取新的拜访令牌。因而，咱们会将用户重定向到登录页面，显示一条“Session expired”的提示信息，让其登录之后，从新获取拜访令牌和刷新令牌。

本文前一章节，从某宝首页登录说起已经提到，咱们在电商网站上购物，如果不小心刷新了浏览器，只有客户端存储的 Cookie 尚未过期，就可依然放弃登录状态。这样，客户刷新之前的会话，比方增加商品到购物车，或者正在进行结帐的某一步，依然处于无效状态。

SAP Commerce Cloud UI 通过将拜访令牌长久化到浏览器的 Local Storage 中来实现上述场景。
每当用户胜利登录后，咱们将 Commerce 后盾服务器颁发的拜访令牌进行长久化存储，保留到浏览器 Local Storage 中。

每次 SAP Commerce Cloud UI 初始化时，通过 Angular APP_INITIALIZER 这个注入令牌，咱们开发了 AuthStatePersistenceService 服务，将浏览器本地存储中的令牌同步到内存中。

采取这种设计后，即便用户在购物过程中刷新了浏览器，SAP Commerce Cloud UI 从新加载后，从 Local Storage 中取出拜访令牌同步到内存中，接下来的用户操作，持续应用该令牌调用 Commerce OCC API，不会因浏览器刷新而中断。

总结起来，SAP Commerce Cloud UI 无关拜访令牌和刷新令牌的应用场景如下：

(1) 用户登录后，SAP Commerce Cloud UI 将服务器颁发的拜访令牌存储于内存中，并长久化到浏览器 Local Storage.
对于刷新令牌，出于安全性思考，咱们团队实现时，仅将其保护在利用内存中，并不进行长久化操作。

(2) 当用户操作 UI，触发 API 调用后收到服务器返回的拜访令牌过期的谬误之后，SAP Commerce Cloud UI 主动利用刷新令牌，申请新的拜访令牌；待拿到新的拜访令牌之后，应用该令牌从新调用之前因为旧的拜访令牌过期而失败的 API；这一系列机制对于用户来说齐全通明，用户在界面上的操作不会受到任何影响。

(3) 如果用户操作触发的 API 调用收到的服务器返回为刷新令牌过期，SAP Commerce Cloud UI 会暂存以后用户浏览页面的 URL，并将用户重定向到登录页面；用户从新登录后，获取到新的拜访令牌和刷新令牌，再被 SAP Commerce Cloud 重定向到刷新令牌过期时正在操作的页面。

总结

本文抉择了国内外两款最具代表性的电商购物网站，应用 Chrome 开发者工具进行探索，剖析了这两款电商网站用户会话管理机制的设计原理，并从前端实现源代码层面进行了分析，分享了用户会话治理的各种 Boundary Condition(边界状况)下实现的注意事项。