问题现象

在业务系统B登录之后，打开B系统的一个内嵌iframe页面page1，page1需要访问业务系统A/create接口，屏幕出现一片白色，跟踪chrome network发现请求截图如下：

可以发现，浏览器在不断的访问A/create接口，然后访问passport/serviceLogin接口，然后访问A/sts接口，然后再次访问A/create，再次访问passport/serviceLogin，再次访问A/sts，陷入死循环．

单点登录流程图

上方流程图是梳理了单点登录代码拦截器和校验代码得出来的，可以发现在第7步，如果serviceToken合法，则创建登录session，后续的接口请求将不会被要求重新登录．如果serviceToken验证不合法，导致重复步骤2，又去passport登录．

问题分析

serviceToken是在第5步通过passport重定向时带回来的authToken和sign转换生成而来，理论上不会出现验证不合法的情况．跟踪了如下图/sts接口请求响应里返回的serviceToken，在response cookie里返回的是KTHeRW……,

下一次请求待/sts的时候带过来的request cookie如下：

奇怪的事情发生了，request cookie里居然带过来两个serviceToken，上面的是F7dJD……，下面的是KTHeRW……,KTHeRW……这个cookie正是上一步请求写入的，如果本次请求只有这一个cookie，应该是可以校验成功的，问题出在多出了第一个同名cookie，那么第一个serviceToken是哪里来的呢？

如下方截图可以发现，这是业务系统B域名下可以访问的cookie,cookie的domain是.,当请求业务系统A(),业务系统B生成的cookie会被带到A系统的请求中

知识点Cookie和域名的匹配规则：

先谈一下Cookie的限制，对于一个任何Http Request来说，提交给Server端的时候，它能够安全访问的Cookie的域名必须在这个HTTP Reuqest的域名路径中。举例来说，发出一个http://communiy./的 请求时，随着这个http request一块发送到server端的cookies会自动包括所有 以 community., ., , ., 为域名的Cookies，这是由Cookie本身的规范所限制的，浏览器如果不是按照这个规范实现，那么就会存在严重安全漏洞，因为那样的话意味着任何一 个服务器都可以读到同一个用户访问别的网站时留下的Cookie。(引用自：/a4875030/article/details/19296481)

问题解决

到这里，问题就明确了，B系统在接入单点登录的时候也在cookie里写入了serviceToken，这个serviceToken如果在A系统的serviceToken之前生成，那么访问A系统的时候，B系统生成的serviceToken会被错误的带到A系统的请求中去，导致A系统登录校验失败，引发单点登录死循环．代码改动如下，将cookieDomain从改成B.xiaomi.ocm，就可以解决这个问题了．

修改之后：再次访问A/create,请求cookie如下，只带了一个serviceToken,而且这个serviceToken是A系统自己生成的那个

总结

a.设置cookie的时候，指定domain一定要慎重，大多数情况下domain都是设置的本系统自己的域名，如果设置的域名过于宽泛，可能会导致该域名的子域名系统拿到同名的错误cookie.

b.这个问题是偶发的，比较难以复现和定位，如果A系统在B系统之前生成serviceToken，那么A系统就可以正确拿到自己的serviceToken，就不会有问题．这个系统在设计的时候，在B系统登录的时候，会去调用A系统接口，如果A系统此时没有登录，两个系统相当于同时在进行单点登录，同时生成serviceToken，这个在架构上设计不是很合理．

如果觉得《Cookie Domain设置错误引发的单点登录死循环问题》对你有帮助，请点赞、收藏，并留下你的观点哦！