登录对接CAS-跨域导致的一个意想不到的Bug

背景描述

业务需求是平台登录，接入Cas验证

问题描述

平台登录页，点击登录方式，跳转Cas登录页，提交登录请求，结果发现，又返回平台登录页；
再次点击登录方式，登录成功，跳转到目标页面。

问题排查

排查方向-浏览器兼容性问题

这个问题，开发人员在其本地开发环境复现不了，仅在我本机可以，因此，他们初步怀疑，这个是浏览器兼容性问题。开发人员经过一段时间排查，终究没找出问题所在。

排查方向-跨域问题

笔者无意中发现，登录成功后，再次退出登录，然后重复该动作，这种情况下是，问题是不可复现的，但通过点击流量收藏夹中的网址，实现登录时，问题就重现了。

于是，仔细检查了下收藏的网址，发现是网址使用的是http协议，非https，然后我很开心的告诉开发，这种情况下能复现。

经过一番分析后，开发人员得出了结论，就是跨域问题，导致前端获取不到存储到localStorage中的Token(最终会存储为Cookie)，所以访问后端时，没有携带该token值，最终登录失败，并基于此准备一些相对复杂的解决方案。

根因分析与解决方案

根因分析

结合自己的分析，及开发的解释，依旧是云里雾里，感觉开发没有说清楚里面的逻辑，终不能说服自己，于是结合请求过程，同开发进行二次探讨。

以下是整个操作过程中，笔者抓取的一些关键请求信息

访问前台页面

GET http://target.sit.example.com/

自动触发登录检测请求

GET http://target.sit.example.com/api/admin/checkLogin

关键响应头及响应体

Set-Cookie: _TOKEN_KEY_=; Path=/; Expires=Thu, 01-Jan-1970 00:00:00 GMT; Max-Age=0

{"msg":"to login","result":{"redirect":"https://wcas.sit.example.com/cas/login?service=https%3A%2F%2Fmg.sit.example.com%2Fapi%2Fadmin%2Flogin%3FloginType%3DCAS-DATA"},"succ":"jump"}

检测结果为未登录，程序根据目标平台提示，跳转Cas登录页

GET https://wcas.sit.example.com/cas/login?service=https%3A%2F%2Fmg.sit.example.com%2Fapi%2Fadmin%2Flogin%3FloginType%3DCAS-DATA

提交Cas登录

POST https://wcas.sit.example.com/cas/login?service=https://mg.sit.example.com/api/admin/login?loginType=CAS-DATA

关键响应头：

Location: https://mg.sit.example.com/api/admin/login?loginType=CAS-DATA&ticket=ST-43509-fE0FeJmFdA3TlLW9dV9Y-casnode1&language=zh&country=CN&variant=CN
Set-Cookie: CASTGC-D-SS="";Version=1;Path=/cas;Domain=.sit.example.com;Expires=Thu, 01-Jan-1970 00:00:00 GMT;Max-Age=0
Set-Cookie: CASTGC-D=TGT-939448-9ZhaREwusKuYIvucwdASdPOoCx6yIwpopNWdhS4M2Ousq2Opsu-O2QFU3-casnode1;Path=/cas;Domain=.sit.example.com
Set-Cookie: CASTGC-D-SS=TGT-939448-9ZhaREwusKuYIvucwdASdPOoCx6yIwpopNWdhS4M2Ousq2Opsu-O2QFU3-casnode1;Path=/cas;Domain=.sit.example.com;HttpOnly;Secure;SameSite=None

根据服务器返回302响应状态码及location请求头，自动重定向

GET https://mg.sit.example.com/api/admin/login?loginType=CAS-DATA&ticket=ST-43509-fE0FeJmFdA3TlLW9dV9Y-casnode1&language=zh&country=CN&variant=CN

关键响应头

Location: https://target.sit.example.com/#/home?token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiIwMTM2NzU5OSIsImV4cCI6MTY4MDI2NzE0M30.auqOB37uknCdoleGdEyCjpUoPlrEtsoV4z1p4zWmpsI&loginType=CAS-DATA
Set-Cookie: JSESSIONID=node0vltj8s5ysap840ozd62zcyau14488.node0; Path=/
Set-Cookie: _TOKEN_KEY_=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiIwMTM2NzU5OSIsImV4cCI6MTY4MDI2NzE0M30.auqOB37uknCdoleGdEyCjpUoPlrEtsoV4z1p4zWmpsI; Path=/

根据服务器返回302响应状态码及location请求头，自动重定向
```
GET https://target.sit.example.com/
```

自动触发是否登录检测请求

https://target.sit.example.com/api/tenant/checkLogin

关键请求头

Cookie: JSESSIONID=node0hjccl321oho11ioud9caco7bg14483.node0; _TOKEN_KEY_=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiIwMTM2NzU5OSIsImV4cCI6MTY4MDI2NzE0M30.auqOB37uknCdoleGdEyCjpUoPlrEtsoV4z1p4zWmpsI

关键响应

HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=node01bh0somchrk8d109bhvjeav6ji14490.node0; Path=/
Set-Cookie: _TOKEN_KEY_=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiIwMTM2NzU5OSIsImV4cCI6MTY4MDI2NzE0NH0.qFHISyVRkWcpP7QYkgmb0K32NKhHxUInNQWTNFTfrx0; Path=/

{"msg":"","result":{"accountModifyNum":0,"contacts":"赖大家","email":"","entTenantCode":"WPMJ1d20230317111905","entTenantType":2,"phone":" ]  }","registerTime":"2023-03-17","tenantCode":"WPMJ1d20230317111905","tenantType":2,"userAccount":"cNmSiwUONW","userStatus":1,"userType":1},"succ":"ok"}

结合上述请求过程，和开发讨论哪一步导致登录失败，结论是上述第5步，也就是使用ST换取token后。

和前端开发人员沟通，第5步执行完成后，需要将程序返回的token存储到Cookie中，开发截图代码如下

从上图可知，token是在重定向完成后，通过获取浏览器中查询参数获取的，这里对开发提出质疑，这一步能否获取到参数，开发最终验证的结果是可以取到值。

按理，此时代码存储token，按理也是存储到https协议的域名下面，不应该是存到http协议的域名下。所以，提出假设，这里window.localStorage.getItem('loginType')未获取到值，因为这个一开始是访问的http协议的站点时存储到localStorage中的，此时访问的是https协议的站点，跨域了，所以取不到值，导致后续的请求Cookie没有携带对应的Token值。

基于这个假设，让开发去掉获取登录类型的判断，然后构建验证，结果发现成了。

那如何解释，第二次点击登录方式就成功登录呢？此时已经是https协议了，二次点击时不存在跨域问题，重新执行一次登录请求，因为上次登录过Cas，所以不会再调跳转Cas登录页，然后就成功了。