共计 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…
更多浏览
- 从产品展现页面谈谈 Hybris 的特有概念和设计构造
- 从产品展现页面谈谈 Hybris 系列之二: DTO, Converter 和 Populator
- Hybris Enterprise Commerce Platform 服务层的设计与实现
- 从一个理论的例子登程,谈谈 SAP Commerce Cloud 电商云的 UI 自定义开发
- SAP Commerce Cloud (电商云) UI 的懒加载性能
- SAP CRM Fiori 利用和 SAP Commerce Cloud (电商云) UI 如何通过调整 CSS 来扭转 UI 显示格调
- SAP 产品一脉相承的 UI 加强思路,在 SAP Commerce Cloud (电商云) UI 加强实现中的体现
- Jerry 在 2020 SAP 寰球技术大会的分享:SAP Spartacus 技术介绍的文字版
- 一小时外在本地搭建 SAP Commerce Cloud(电商云)的前后台运行环境
- SAP Commerce Cloud (电商云) 路由门路的自定义配置与开发
更多 Jerry 的原创文章,尽在:” 汪子熙 ”: