实现过程 目前浏览器无法提供区分 Tab 的方法，即无法使用浏览器端接口获取到 Tab 的标识。Web 网站使用 SSO 的技术，服务器在认证用户的身份之后，通常会给客户端返回一个固定 Key 值、用于身份识别的 Cookie (此处涉及到会话跟踪技术三)。在此浏览器后续的请求中，客户端（浏览器）会将此 Cookie 提供给服务器端用于身份识别，如图 1 所示。由此可见，无论是客户端还是服务器端都未曾考虑同一账户多 Tab 下的不同会话的跟踪问题。
图 1. 固定 Cookie Key 认证过程 解决这个问题首先需要使用不同的 Key 作为身份标识提供给客户端。过去 SSO 产生的 Token 存储在客户端类似于这样的格式 AUTH=xyz。其中 AUTH 是 Key，xyz 是 Value。由于这是身份认证的信息，Value 一般是加密存储的，防止恶意盗取会话信息。
为了识别不同 Tab 下的会话，新的 Token 存储的方式需要不同的 Key，例如：AUTH-456784567345=xyz。AUTH 是这个身份认证 Cookie 标识的前缀,而数字串 456784567345 则是服务器端随机生成的一个 Long 型数字作为后缀，用来区分 Tab 身份。
如果用户在三个 Tab 下对同一个网站登录了不同的身份，那么会出现三个 Token，而过去只有一个。那么在任何一个 Tab 下操作，请求发送到服务器端的时候，客户端都会将此三个 Token 带到请求里，服务器需要知道到底哪一个 Key 才是当前 Tab 的身份信息，如图 2 所示：
图 2. 可变后缀 Cookie Key 的认证过程 因此，客户端需求在发送请求的时候告诉服务器端身份标识的后缀。完成登录认证的时候，服务器端返回给客户端主页面的时候，服务器端可以将此后缀隐藏在某个子页面中（HTML 代码是 Tab 隔离的，此处涉及到会话跟踪技术二）。代码如：<input type="hiden" name="auth-suffix" id="suffix" value="" />。此子页面一直存在于会话登录中，例如网页的导航栏。大多数的客户端请求有两种，一种是 GET 请求，一类是 POST 请求：
- 对于 GET 请求，需要客户端脚本将请求的 URL 后添加后缀的参数（此处涉及到会话跟踪技术一），例如：https://www.hostname.com/app?suffix=456784567345
- 对于 POST 请求，可以将后缀放在 POST 请求的 Parameter 参数里。JQuery 代码：params={"suffix": "456784567345"}; $.ajax({type:"
 OST", url:https://hostname/url, data:params, datatype:"json", success )=>{}});
如此一来，服务器端就可以获取浏览器某个 Tab 的后缀，近而取得相应的 Cookie 来获取这一 Tab 的身份信息了。
为了提高安全性，此实现方式还需要服务器端实现会话管理（此处涉及到会话跟踪技术四）。
如果会话管理服务器只有一个节点，可以使用简单的 Map 进行管理。Map 的 Key 是 Session ID，Map 的 Value 是 Session 对象。首先，服务器端从浏览器端提交的请求中获取 Cookie 的后缀参数值，进而得到 Cookie 的 Key (固定前缀+后缀)。由于 Cookie 的存储结构也是 Map，服务器端即可获取到对应 Cookie 的 Value。解密之后，得到 Cookie 中存储的服务器端 Session ID。服务器端通过 Session ID 获取到 Session 对象，得到存储在 Session 对象中的用户信息。
如果会话管理服务器是集群的组织结构，那么可以采用支持集群的 Redis 等框架实现服务器会话管理服务。如果读者对 Redis 技术有兴趣，可自行查阅相关文章资料，本文不再详述。
总结大部分的网站并没有支持 Tab 级会话跟踪。然而这一技术在公有云的普及下，变得越来越重要。虽然用户可以通过启动多浏览器的进程来规避此问题，但是多浏览器的操作也会给用户带来需要切换浏览器和耗费更多的计算机资源的弊端。 |
