最近在做单点登录对接，其流程如下
B系统携带ticket请求A系统获取token之后，A系统会删除ticket记录，因此ticket只能用一次，如果A系统接收到了相同的ticket换取token的请求，就会报错，我遇到的就是这个问题：B系统十次里面会有两三次都会收到两次ticket请求，所以B系统会拿着ticket请求A系统两次，第一次成功，第二次失败，页面上显示失败信息。
一开始以为B系统代码有问题，但是B系统从access log上来看，确确实实收到了两次请求。。A系统在单点的时候，实际上是新开了浏览器tab页，然后访问了单点的地址，不可能存在重复请求的问题，否则不得新开两个tab页了。。到底是什么原因呢？
为了更清晰的看到单点过程，然后我使用了charles抓包看了下
根据时间顺序，我在上图标注了下1/2/3，它们三个地址是一样的，1是http地址，2/3是https地址，2是成功的请求，3是失败的请求，（其实看到这个我心里已经大概知道是什么原因了）：
第一个请求：请求http，但是nginx配置了自动跳转https，所以重定向到了2
第二个请求：http重定向到了这里，正常的单点登录处理之后，重定向到正常的成功页面
第三个请求：和2一样的https请求，就因为这个请求，前端页面才显示单点登录失败的，但是它又是谁发起的呢？这失败的原因关键就在于此，该次请求不总是有，所以展示的结果就是有时候成功，有时候失败。
实际上第三次失败的请求是谷歌浏览器自动发起的，百度搜索“谷歌浏览器自动跳转https”，能搜索到很多相关的信息，谷歌浏览器在地址栏贴上http请求，有可能会自动跳转到https的地址，如果不是手动贴上去，就算是程序这么干，谷歌浏览器也会有一样的行为。
真相大白了，先是nginx配置了强制https，所以有了第二次的正常请求；同时，谷歌浏览器也有自动转换https的机制，所以会有第三次相同的请求，解决方法其实很简单，把配置的http地址改成https地址，既不会发生nginx强转了，谷歌浏览器也不会有什么诡异操作了
改成https地址之后，一切正常了， end.
注意：本文归作者所有，未经作者允许，不得转载