浅谈电子商务网站开发研究中用户session管理机制的设计与实现原理，在此将自己学到的一些知识分享给同行，希望能起到抛砖引玉的作用。我们先来看一下大家日常生活中使用的某宝网站的用户会话管理机制。在电脑上访问某宝网，输入用户名和密码，点击登录：你会观察到一个HTTPPost请求，登录，发送到后台服务器：https://login.taobao.com/newl。..请求的FormData包含两个字段，loginId和password2，分别维护用户输入的用户名的明文和密码的RSA加密值。下面介绍如何找到前端对用户输入的登录密码进行RSA加密的具体位置。在Chrome开发者工具中找到登录请求，在Initiator面板中找到发起请求的调用栈。有经验的前端开发者从onClick和t.loginSubmit可以推断，用户名和密码的输入框是用Form形式实现的。点击登录按钮后，触发表单的提交。打开上图中找到的索引。js文件：https://x.alicdn.com/vip/hava...直接搜索关键词password2，很快就会找到RSA加密代码位置：设置断点后，运行时点击登录按钮，然后断点会触发，可以进入rsaPassword函数查看RSA加密算法的详细信息。在这个index.js中还有一些有趣的东西可以找到。比如在提供rsaPassword方法的模块内部，还维护了一个支持的国家列表countryList，里面包含了168个国家和地区：但是当你在浏览器端打开一个网站的时候，在国家和地区的下拉列表中地区，只能看到十多条记录。按照某种逻辑，这应该是前台某处的一个过滤器：另外，我们可以在这个电商网站的首页右侧区域看到话费快充的面板，如图中绿色高亮部分下图区域：该页面的HTML源代码，不是静态写在首页的HTML文件中，而是通过一个名为bianming-phone的HTTP请求（“便利”的拼音加上“手机”的英文单词phone)，从后台读取到前台，然后注入到首页：同样，还有这个旅行视图片段（相当于SAPUI5中的ViewFragment）：读取这个视图片段的HTTP请求：bianming-trip看到这里，笔者不禁想到了前面的SAPCommerceCloudCMS驱动设计，都是从连接电商页面的后台系统读取部分页面配置信息，可谓是相同的。SAPS/4HANA的UI风格是FioriUX，实现的前端框架是SAPUI5；SAPCommerceCloudUI实现的前端框架是Angular；help.sap.com使用AngulaJS实现，www.sap.com使用React。淘宝网的首页使用了阿里开发的前端框架。Kissy：我们在Treasure.com首页看到了各种产品图片，都是由Kissy驱动，通过CDN服务器发起的数据请求加载的：在这些页面片段的源代码中也有一些有趣的内容，比如这种“上线请删除”的评论。我现在浏览的是上线后的代码。为什么我还能看到这些评论:)我们在电商网站购物的时候，选择自己喜欢的商品，加入购物车后，当然不想点击结账了。突然弹出一个要求重新登录的界面，岂不是很扫兴。另外，当我们不小心误操作点击了浏览器刷新按钮时，我们期望页面刷新后，我们仍然是登录状态，加入购物车的商品不会丢失。这些都属于用户会话管理的范畴。宝藏网站页面的用户session管理是通过客户端cookie和服务端维护的用户session对象来实现的。用户登录成功后，服务器创建对应的Session对象，返回登录HTTP请求的响应头，其中包含很多set-cookie字段：浏览器解析这些响应，在本地设置服务器下发的Cookie。下次用户再次操作电子商务网站并向服务器触发新的请求时，浏览器会自动将这些Cookie字段设置到请求头中。服务端收到这些cookie字段后，就可以在内存中定位到用户登录后创建的对应Session对象，从而识别用户。这些cookie也可以在Chrome开发者工具中查看。cookie的Expires字段存储过期时间。当Expires为Session时，表示cookie只在当前session中有效，关闭浏览器后cookie自动删除。带HttpOnly的Cookies无法被客户端JavaScript代码读取，提高了安全性，避免了cookies被XSS攻击窃取的可能性。Secure为true的cookie不能通过HTTP协议传输到服务器，只能通过HTTPS发送。电商网站服务器下发的cookie中，字段lid存储的是用户名经过URL编码后的值，dnk存储的是用户名的Unicode：再看国外的另一个电商网站，SAPCommerceCloud的用户会话管理机制的设计与实现。SAPCommerceCloudUI基于100%API驱动的无头电商架构，Commerce后台通过OCC（OmniCommerceConnect）API暴露Commerce的核心业务。借助这些API和开源SAPSpartacus库，客户可以开发具有个性化用户体验的电子商务网站。SAPCommerceCloud有一个名为Oauth2的扩展，它基于OAuth2.0协议实现用户身份验证和令牌颁发/功能，并支持OAuth2.0协议定义的所有四种身份验证流程，包括ResourceOwnerPasswordFlow。SAPCommerceCloudUI在OAuth2.0认证框架中扮演客户端角色，通过消费SAPCommerceOauth2扩展提供的OAuth系列API实现用户会话管理。让我们从初始用户登录场景开始。输入用户名和密码：SAPCommerceCloudUI调用CommerceOAuth2API，端点为/authorizationserver/oauth/token，将用户名、密码、client_id和client_secret交换为AccessToken和RefreshToken。这里的SAPCommerceCloudUI作为OAuth认证系统中的客户端，其client_id和client_secret在CommerceBackoffice中配置：服务器端验证通过后，会下发accesstoken和refreshtoken，如图下图中的access_token和refresh_token字段：SAPCommerceCloudUI在OAuth系统中的角色是客户端，通过accesstoken获取访问Commerce后台服务器上业务数据的权限。当访问令牌过期时，客户端使用刷新令牌来交换新的访问令牌。refreshtoken本身就是一个凭证，表明持有它的客户端已经通过了OAuth认证，获得了访问受保护资源的权限。当通过刷新令牌再次请求新的访问令牌时，客户端不必从头开始。完成OAuth身份验证的完整过程。SAPCommerceCloud的accesstoken和refreshtoken都有过期时间，有时也叫TTL（Time-to-Live，生存时间），默认值分别是12小时和30天。我们团队的开发人员，在开发SAPCommerceCloudUI用户会话管理功能和测试各种边界条件时，为了方便，通常会在他们本地搭建的Commerce服务器上调整token的过期时间。例如下图的例子，两者分别调整为30秒和60秒后过期：获取到accesstoken后，在CommerceCloudUI消费时附加到HTTP请求的header字段后台OCCAPI：如果此时accesstoken已经过期，请求会收到服务器的401错误响应：以及错误详情InvalidTokenError:Accesstokenexpired:IqQ-8cYzHV1gjQOpnYytHTFPt30显然这种技术错误信息不应该显示给用户，幸好我们还有刷新令牌。此时SAPCommerceCloudUI会将过期的accesstoken连同refreshtoken一起发送到Commerce后台申请新的accesstoken：当SAPCommerceCloudUI首次登录申请token时，grant_type的值为password；当accesstoken过期，使用refreshtoken重新申请时，grant_type的值要填refresh_token。refreshtoken的过期时间也到了怎么办？没有刷新令牌，就无法获得新的访问令牌。因此，我们会将用户重定向到登录页面，显示“Sessionexpired”的提示信息，要求用户重新登录，获取accesstoken和refreshtoken。本文上一章从某宝首页登录开始讲到，我们在电商网站购物时，如果不小心刷新了浏览器，只要把客户端保存的cookie没有过期，我们仍然可以保持登录状态。这样，客户刷新的前一个会话，例如将商品添加到购物车，或者进行结帐的某个步骤，仍然有效。SAPCommerceCloudUI通过将访问令牌保存在浏览器的本地存储中来实现上述场景。每当用户成功登录时，我们将Commerce后台服务器颁发的访问令牌持久化并保存在浏览器的LocalStorage中。SAPCommerceCloudUI每次初始化时，通过AngularAPP_INITIALIZER的注入token，我们开发了AuthStatePersistenceService服务，将浏览器本地存储中的token同步到内存中。采用这种设计后，即使用户在购物过程中刷新了浏览器，在SAPCommerceCloudUI重新加载后，accesstoken从LocalStorage中取出并同步到内存中，下次用户操作继续使用用于调用CommerceOCCAPI的令牌，不会被浏览器刷新中断。综上所述，SAPCommerceCloudUI对accesstokens和refreshtokens的使用场景如下：(1)用户登录后，SAPCommerceCloudUI将服务器下发的accesstoken存储在内存中，并持久化到浏览器本地存储。为了安全起见，我们团队在实现refreshtoken时，只维护在应用内存中，不进行持久化操作。(2)当用户操作UI，触发API调用，收到服务器返回的accesstoken过期错误时，SAPCommerceCloudUI自动使用refreshtoken申请新的accesstoken；获取新的访问令牌后，使用该令牌重新调用因旧访问令牌过期而失败的API；这一系列机制对用户是完全透明的，用户在界面上的操作不会受到任何影响。(3)如果用户操作触发的API调用返回的服务器提示refreshtoken已经过期，SAPCommerceCloudUI会暂存当前用户浏览页面的URL，并将用户重定向到登录页面;用户再次登录后，访问新的访问令牌和刷新令牌，然后由SAPCommerceCloud重定向到刷新令牌过期时它正在操作的页面。总结本文选取国内外最具代表性的两个电商购物网站，使用Chrome开发者工具进行探索，分析这两个电商网站的用户会话管理机制的设计原则，并从前端实现源代码级别。经过分析，分享了实现用户会话管理各种BoundaryCondition的注意事项。
