单点登录cookie注销（单点登陆-cookie共享）

由于最近在改动之前写的《最好理解的“单点登录-共享cooike”方案》文章中附赠的代码时，突然发现那篇文章中的“登陆”与“退出登陆”的设计方案在“数据流转过程”上是不对称的，虽然可以达到目的，却可能给人一种设计混乱的感觉。所以最后将代码稍作了修改，今天写这篇文章就是就将改动后的方案与之前的方案进行一下对比说明。

首先，我们来看一下“单点登录-共享cooike”方案中的登陆请求过程图：

登陆请求过程图

由图中你可以看到，此次设计中，sso认证中心只承担了接口认证的任务，即所有的数据从客户端向认证中心发起，拿取到数据后再由客户端向所有客户端请求数据。

那么相应的，在设计退出登陆流程时，也应该遵照这种设计方案以达到“整体方案中数据流转过程的一致性”的目的，故，在本次示例代码修改后的方案如下所示：

退出登陆请求过程

退出登陆流程图

从以上的请求过程中，你可以看到：

1. 认证中心依然是作为一个后端服务存在的，即，它没有直接暴露给客户端（前台）以致直接交互；（这一条是与之前文章中的设计方案最不一样的地方）
2. 从数据流转过程上来说，此设计与登陆流程是具有一致性的：都是从客户端出发、流经认证中心、再流到各个客户端；

从以上两点上来说，本方案与之前《最好理解的“单点登录-共享cooike”方案》文章中提到的退出登录方案是不同的（示例代码已经改成此方案）。

然而，本方案虽然从设计上极大地满足了强迫症患者的心理，但不得不说，从数据完整性上来说它是有欠缺的，具体我们来贴一下之前方案的设计图，并且分析一下之前方案的优势：

退出登陆流程图

本方案二中，当退出登陆时，客户端是直接请求认证中心的退出登陆接口，也就是比起“方案一”：

1. 从请求链路上来说，减少了流转到客户端服务器的过程，从而减小了可能出现请求失败的可能性；
2. 从数据一致性、完整性来说，与登陆时相反的数据流转方向是最能保证数据一致性的方案。即，在登陆时，数据从客户端出发、最终到达认证中心；而在退出登录时，则应该先清除认证中心的数据、继而再清除各个客户端的数据才是较为妥当的方式；

以上两点是我当初设计时所考虑的原因，特别是第2条占了主导地位，但单单从设计方案的统一性方面来讲，我更欣赏方案一，而方案二其实更适合“单点登录-中央认证服务（CAS）”的设计流程（如果想了解该方案，或，想后续获取代码的话，请关注我后续的文章）。

至此，两种方案的对比说明到此结束，感谢您的阅读；如有问题，随时留言。

注：方案一的代码请从文章末尾的“了解更多”获取！