问题描述免费试用 IBM Cloud
利用 快速轻松地构建您的下一个应用程序。您的免费帐户从不过期,而且您会获得 256 MB 的 Cloud Foundry 运行时内存和包含 Kubernetes 集群的 2 GB 存储空间。 并确定如何开始。如果您不熟悉 IBM Cloud,请学习 。
软件即服务 (Software as a Service) 公有云平台 (如 IBM Cloud) 运营商提供各种各样的服务,用户可以根据自己的需要选择相应的服务。当用户需要某一种服务时,需要登陆服务提供商的网站,创建这一服务的一个实例(instance)来作为服务实体。与此同时,服务提供商会为这个实例创建一个凭证(credential)作为其他 SDK 方式连接的凭证。同一用户可以拥有多个实例来作为不同服务的实体。用户登录以后,客户端存储了服务器端生成的特定 Cookie 做为身份认证。网站认证大多采用单点登录(Single Sign On,简称 SSO)技术,而特定的网站存储在同一浏览器的身份 Cookie 只有一份。如果同一用户在同一个浏览器的多个 Tab 下操作不同的实例,那么服务器端无法区分请求的主体是哪一个实例,从而导致两个实例的操作在服务器端混为一起。
解决思路 由于 Cookie 在同一浏览器中是共享的,所以服务器端无法通过 Cookie 区分不同 Tab 中的会话。而且,前端页面无法用脚本的方式获取浏览器 Tab 标识。因此,要跟踪 Tab 级别会话,就需要一个能在 Tab 级别跟踪会话的令牌(Token)保存于 Cookie 中。
Cookie 在客户端以键值对(Key-Value)的形式来存储,一个 Cookie 就是一对 Key-Value。通常经过身份验证之后,Web 网站为会话生成一个固定 Key 的 Cookie,并存储在客户端。客户端在发起新的请求时将此 Cookie 一并传送给服务器端用于身份识别。
为了彻底的分离多 Tab 下的会话,在服务器端生成会话的时候,可以为每一个浏览器 Tab 生成一个不同 Key 的 Cookie,并将此 Key 记录在返回的 HTML 页面中。HTML 页面是 Tab 隔离的。此客户端向服务器发起新的请求时,客户端将预存在 HTML 中的 Key 传给服务器端。服务器端获取到客户端传递的 Key 值之后,就可以获取到对应的身份 Cookie。
本文将综合多种会话跟踪技术解决不同 Tab 之间跟踪不同会话的问题。
会话跟踪技术会话跟踪是 Web 应用的基础技术之一。目前主流的会话跟踪技术有以下四种:
- URL 重写:URL 是互联网统一资源定位符。URL 重写的技术是将一段附加数据添加到 URL 的路径上。通常附加数据包含会话 ID。会话 ID 是服务器端存储特定会话对象的标识。
- 隐藏表单域:将会话的 ID 存储在表单的隐藏元素中。用户提交表单时,会话的 ID 一起被提交到服务器端。
- Cookie:Cookie 是以键值对的结构存储在浏览器端的一段文本信息。服务器端可以将特定的信息,例如会话 ID,包含在用户请求的响应中返回给浏览器端。在新的请求中,浏览器会自动携带存储的 Cookie 提交到服务器端。
- Session:HTTP 协议是无状态的,同一系统的不同资源只允许有对应权限的用户访问。用户登录之后,客户端和服务器端需要维持会话。通常服务器端会提供会话管理的机制,将不同客户的身份信息存储在不同的区域。浏览器向服务器发起请求时,需要提供会话 ID,这样服务器端就可以获取到对应客户端的身份,返回请求的资源。
在本问题的解决方案中同时使用了以上四种技术。 |