Open jingzhiMo opened 3 years ago
有运营同学反馈，在我们的系统上的用户信息不同步。在其他系统的用户信息会同步...
这位运营同学有两种账号：
通常来说，一般人都只有一个个人账号；但是运营需要切换为公共账号，使用该账号的权限来统一发布东西。而他遇到的情况就是，在系统 A 上从个人账号切换公共账号，然后打开我们的系统 B；发现系统 B 上看到的用户信息还是个人账号。而这个时候，他打开系统 C、D 看到的账号信息，却是公共账号。
上面说的A,B,C,D这些系统，都是由同一个后端应用来处理，每个系统的域名是一级域名相同，二级域名不同，例如：
https://a.example.com https://b.example.com https://c.example.com https://d.example.com
我这边后面也申请了一个公共账号，也是按运营同学的执行步骤来执行：
从这个现象发现，并不是只有 B 系统才会出现的问题，其他系统应该也会有一定概率会出现账号信息不同步；通过附近另外一个同学也来验证，系统账号信息同步具有“随机性”。也就是说，这几个系统之间，都有可能出现不同步的情况。
在当时想的推测方向：用户信息校验不同步。但是导致这个不同步是服务器(多台服务器) session 之间没共享？还是客户端 cookie 不同？还没解决。
从上面的背景可以了解到系统架构简略图如下：
不同应用的域名都解析到同一个后端应用，而后端应用对接 SSO 系统。
从上面“问题重现”中说到的推测：
但是导致这个不同步是服务器(多台服务器) session 之间没共享？还是客户端 cookie 不同？还没解决。
假设由于 session 是因为服务器之间没有同步，应该会在一段时间内进行同步完毕；但即使过了两三分钟，账户信息还是没同步。从这个粗暴的观察方法，这个假设成立度很低。
那就剩下一个原因：cookie 不同，导致服务端在认证用户的时候，辨别到不同的用户。通过调查发现，后端应用会通过解析 cookie 的其中一个字段(token) 来提取用户的信息。这一个 cookie 是挂在具体二级域名下面的，也就是：A.example.com，不是泛一级域名*.example.com。
A.example.com
*.example.com
所以实际上，A,B,C,D 这些系统之间的用户信息其实都是隔离的，只是有些“局部现象”误导了我们，这些系统之间是互通。那么这些“局部现象”应该怎么解释呢？
SSO 登录系统用来解决多个应用统一的登录问题，减少用户在每个系统上都需要一套账号密码的麻烦程度，能够让各个系统统一登录状态。例如上面说的，有4个系统，通常只要在一个系统上面登录了，在另外几个系统就能够做到“免登”的效果。
下面的图是简单描述了一个系统通过 SSO 来进行登录的过程；
假设用户没有登录过 A.example.com的系统，而且输入的账号密码都是正确：
当用户已经在 A.example.com 登录过之后，再打开 B.example.com 流程如下图
对比以上两张图，对于用户操作来说，打开 B.example.com 就不需要输入账号密码这一步骤，用户信息状态也会进行同步。
B.example.com
这里需要说一下，“过期时间”这个可能是几分钟，也有可能是几个小时，这个是后端应用进行配置。
在步骤分析这一块，校验用户信息的时候，会优先对应用域名对应的 token 进行校验，如果 token 校验通过，则会返回这一个用户的信息。
假设：一开始 A,B,C,D 四个应用都是个人账号。
当用户在 A.example.com 域名下，从个人账号切换到公共账号的时候，再打开 B.example.com，有的用户是同步到公共账号，有的用户还是停留在个人账号。导致这一个现象是第三步校验的不同步。
因为不同用户登录这几个系统的时间不一致，导致 token 的过期时间存在差异。导致，出现部分系统用户信息同步，部分用户信息不同步。
（完）。
背景
有运营同学反馈，在我们的系统上的用户信息不同步。在其他系统的用户信息会同步...
情况描述
这位运营同学有两种账号：
通常来说，一般人都只有一个个人账号；但是运营需要切换为公共账号，使用该账号的权限来统一发布东西。而他遇到的情况就是，在系统 A 上从个人账号切换公共账号，然后打开我们的系统 B；发现系统 B 上看到的用户信息还是个人账号。而这个时候，他打开系统 C、D 看到的账号信息，却是公共账号。
上面说的A,B,C,D这些系统，都是由同一个后端应用来处理，每个系统的域名是一级域名相同，二级域名不同，例如：
分析问题
问题重现
我这边后面也申请了一个公共账号，也是按运营同学的执行步骤来执行：
从这个现象发现，并不是只有 B 系统才会出现的问题，其他系统应该也会有一定概率会出现账号信息不同步；通过附近另外一个同学也来验证，系统账号信息同步具有“随机性”。也就是说，这几个系统之间，都有可能出现不同步的情况。
在当时想的推测方向：用户信息校验不同步。但是导致这个不同步是服务器(多台服务器) session 之间没共享？还是客户端 cookie 不同？还没解决。
系统架构
从上面的背景可以了解到系统架构简略图如下：
不同应用的域名都解析到同一个后端应用，而后端应用对接 SSO 系统。
推测排查
从上面“问题重现”中说到的推测：
假设由于 session 是因为服务器之间没有同步，应该会在一段时间内进行同步完毕；但即使过了两三分钟，账户信息还是没同步。从这个粗暴的观察方法，这个假设成立度很低。
那就剩下一个原因：cookie 不同，导致服务端在认证用户的时候，辨别到不同的用户。通过调查发现，后端应用会通过解析 cookie 的其中一个字段(token) 来提取用户的信息。这一个 cookie 是挂在具体二级域名下面的，也就是：
A.example.com，不是泛一级域名*.example.com。所以实际上，A,B,C,D 这些系统之间的用户信息其实都是隔离的，只是有些“局部现象”误导了我们，这些系统之间是互通。那么这些“局部现象”应该怎么解释呢？
SSO 系统
SSO 登录系统用来解决多个应用统一的登录问题，减少用户在每个系统上都需要一套账号密码的麻烦程度，能够让各个系统统一登录状态。例如上面说的，有4个系统，通常只要在一个系统上面登录了，在另外几个系统就能够做到“免登”的效果。
下面的图是简单描述了一个系统通过 SSO 来进行登录的过程；
假设用户没有登录过
A.example.com的系统，而且输入的账号密码都是正确：当用户已经在 A.example.com 登录过之后，再打开 B.example.com 流程如下图
对比以上两张图，对于用户操作来说，打开
B.example.com就不需要输入账号密码这一步骤，用户信息状态也会进行同步。步骤解析
*.example.com的 token 这一校验步骤，是在后端应用引用 SSO 服务提供的插件来实现的。通常校验会对 token 进行解密，若解密成功，就会对过期时间进行判断；根据这些信息来判断 token 是否有效。这里需要说一下，“过期时间”这个可能是几分钟，也有可能是几个小时，这个是后端应用进行配置。
B.example.com的时候，因为改应用域名校验是不通过的，这个时候应用跳转到 SSO 服务之后；而 SSO 服务拿到对应域名的 cookie，校验用户信息是正确的。就可以免去用户再次输入账号密码的过程。现象解析
在步骤分析这一块，校验用户信息的时候，会优先对应用域名对应的 token 进行校验，如果 token 校验通过，则会返回这一个用户的信息。
假设：一开始 A,B,C,D 四个应用都是个人账号。
当用户在
A.example.com域名下，从个人账号切换到公共账号的时候，再打开B.example.com，有的用户是同步到公共账号，有的用户还是停留在个人账号。导致这一个现象是第三步校验的不同步。B.example.com这个域名下 token 校验不通过，然后跳转到 SSO 校验的时候，SSO 服务域名对应的 cookie 校验通过了，返回公共用户。B.example.com，在第三步校验 token 的时候通过，该 token 没有过期，所以返回还是个人账号。因为不同用户登录这几个系统的时间不一致，导致 token 的过期时间存在差异。导致，出现部分系统用户信息同步，部分用户信息不同步。
（完）。