关于sap:SAP-Commerce-Cloud-UI-的用户会话管理

3次阅读

共计 3270 个字符，预计需要花费 9 分钟才能阅读完成。

这是 Jerry 2021 年的第 51 篇文章，也是汪子熙公众号总共第 328 篇原创文章。

如无非凡阐明，本公众号介绍的 SAP Commerce Cloud UI，均指新一代基于 Spartacus 开源我的项目开发的 UI，而非传统的基于 JSP 技术，同 Commerce 平台耦合在一起的 Accelerator UI.

前文 从淘宝首页登录说起 提到过，淘宝网的用户会话治理，通过浏览器的 Cookie 和服务器端的用户会话对象来实现。

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

对于 SAP Commerce Cloud Headless 架构的更多介绍，请参考我之前的文章：Jerry 在 2020 SAP 寰球技术大会的分享：SAP Spartacus 技术介绍的文字版。

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 重定向到刷新令牌过期时正在操作的页面。

本文简略介绍了 SAP Commerce Cloud UI 用户会话治理的根本实现原理和反对的场景。对其技术实现感兴趣的敌人，能够查阅咱们团队公布在 Github 上的文档，感激浏览。

https://sap.github.io/spartac…

更多浏览