这篇文章主要讲解了“如何解决SSO单点登录重定向”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“如何解决SSO单点登录重定向”吧！
当我们写好SSO单点登录服务的代码后，通过调用接口方式验证，流程看似正常，但开始与前端联调就出现问题了。
流程是这样的：前端在首页使用ajax访问后端获取菜单或者用户信息的接口，以触发登录校验，如果未登录则重定向到SSO登录页面。
但这一步就出问题了，原因是ajax无法拦截302处理。当ajax接收到302响应时，看起来就像是ajax直接向重定向链接发起请求，而不是让浏览器重定向，结果啥事也没干。
关于ajax无法拦截302处理的原因，笔者从网上找到的解释如下。
服务器将302响应发给浏览器时，浏览器并不是直接进行ajax回调处理，而是先执行302重定向，从响应头中读取Location信息，然后向Location中的Url发出请求，在收到这个请求的响应后才会进行ajax回调处理。
大致流程：ajax -> browser -> server -> 302 -> browser(redirect) -> server -> browser -> ajax callback。
原本是为了让前端以最少的改动接入SSO，但因为笔者对前端的了解较浅，才犯了这样的错误。
既然ajax无法处理302，那也只能修改流程，让前端主动发起重定向了。
流程修改后，当后端验证用户未登录或登录过期时响应401状态码，同时body给出重定向链接，而前端需要全局拦截401错误，从响应body获取链接并让浏览器重定向到指定链接，该链接就是由后端拼接好的跳转到SSO登录的链接。
最后还有一个cookie问题。由于本地测试，前端将请求转发给部署到测试环境的后端，前端的域名为127.0.0.1，后端测试环境域名为xxx. com，导致本地测试跳转到SSO登录成功并返回后，前端向后端发起请求依然响应401。
原因在上篇已经描述过了，就是因为域名不同，前端使用ajax发起请求，浏览器并不会将xxx.com域名下的cookie带上，只会带上127.0.0.1域名下的cookie。
解决该问题只需要修改传给SSO登录成功后重定向的checkToken接口的域名为前端本地测试的域名，由前端将请求转发给后端，或者在nginx配置将此接口的请求转发给后端处理，只有这样session才能保持一致。
除此之外，跨协议无法重订向。也就是说，sso部署在测试环境域名为https://sso.xx.com，而接入sso的服务在本地测试域名为http://127.0.0.1，想要从https://sso.xx.com登录成功后重定向回http://127.0.0.1是不支持的，原因是跨协议重定向了，由https协议变成了http协议。
从这些事情可以看出，实战很重要!即便理解了流程、实现原理，但不动手实战就学不到细节，无法从各种踩坑过程中成长。
感谢各位的阅读，以上就是“如何解决SSO单点登录重定向”的内容了，经过本文的学习后，相信大家对如何解决SSO单点登录重定向这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是编程网，小编将为大家推送更多相关知识点的文章，欢迎关注！
