从SSO出发谈谈登录态保护
抛砖引玉 在文章开始前，先看看一个常见的情况 👇 在集团内进行开发时，通常会遇到不同组之间的合作，如果是同一个组的前后端，因为交互请求都是在同一个 「域」 内发生的，所以一般不会存在跨域问题。但如果未做处理，直接从 a.alibaba.com 请求 b.alibaba.com 的接口，就会出现跨域的问题，这是因为浏览器对于不同域请求的限制问题，其实跨域的问题很好解，只要设置了正确的请求头即可，具体的可以参考我的这篇文章 👉《一次跨域问题的分析》 但这是访问不需要登录的接口，那如果是从 a.alibaba.com 访问 b.alibaba.com 下的一个需要登录的接口呢？又该如何解决呢？ 下文以 A 站点指代 a.alibaba.com，B 站点指代 b.alibaba.com 单系统登录 对于一个 web 应用来说，通信协议通常是 HTTP 协议，该协议是无状态的，也就是说，在请求与请求之间是不会产生关联的。这也就意味着，任何用户都能通过浏览器访问服务器资源，且不会打扰到其他用户。如下图所示 👇 如果想要保护某些资源，比如一些珍贵的学习资料，那就必须限制浏览器的请求，对于服务端来说就是要知道发出这个请求的人是谁，也即让请求变得有「状态」，只不过既然 HTTP 协议无状态，那就让浏览器和服务器之间共同维持一个状态吧，而这就是最常见的——会话机制。 Cookie 和 Session 在会话机制中，最重要的就是 Cookie 和 Session 了，Session 好理解，服务端保存的用来维护某一个用户的状态，浏览器只需用某种方式记录下这个会话的 ID 然后之后每次请求携带即可，想必有小伙伴会发出疑问了，既然是给浏览器携带参数，那么直接在请求参数里携带不是最简单的吗？ 的确，将会话 id 作为每一个请求的参数，服务器接收请求自然能解析参数获得会话 id，并借此判断是否来自同一会话，这个思路当然是可以的，只是这种做法的缺点也十分明显，就是请求的 URL 会变得非常长，隐秘性也很差。 而 Cookie 是浏览器用来存储少量数据的一种机制，数据以”key/value“形式存储，并且浏览器发送 http 请求时自动附带 Cookie 信息。此时，有 Cookie 参与的登录请求的流程就变成了下面这样 👇 Cookie 和 Session 的使用原理基本如此，至于这么设置 Cookie，怎么通过 Cookie 校验 Session 就不是本文要说的内容了。有兴趣的可以查阅相资料。...