我么知道 Http 是无状态协议，这意味着服务器无法确认用户信息。于是W3C就提出了给每个用户发一个通行证，无论谁访问都要携带通行证，服务器通过通行证确认信息。这个通行证就是Cookie。Session 相当于在服务器中简历的一份“客户明细表”。Session 不能依据 Http连接来判断是否为同一个用户，于是服务器向浏览器发送一个Cookie，Session就是依据cookie来识别是否是同一用户。
流程：用户信息保存在 Session中 ===》如果Session中可以查到放行，已经登录，如果查不到说明没有登录或者是登陆失败。
总结：用户登录的时候会生成一个Token保存在数据库中，将Tocken写到Cookie中，保存在Session中；每次请求都会带上Cookie，检查有没有登录。
2、多系统登录解决Session不共享问题系统简单结构如图所示 ：
以下几种解决方案：
1、Tomcat集群Session全局复制（集群内每个tomcat完全同步）【影响性能不建议】
2、根据IP请求进行 Hash映射到对应的机器上（不建议）。
3、把Session数据放到Redis中（使用Redis模拟Session）【建议】
2.1、我们可以将登录功能单独抽取出来，做成一个子系统。 （俗称SSO）总结：
* SSO系统生成一个token，并将用户信息存到Redis中，并设置过期时间
* 其他系统请求SSO系统进行登录，得到SSO返回的Token，写到Cookie
* 每次请求Cookie都会带上，拦截器得到token，判断是否登录。
两个变化：
a、将登录系统抽取为一个系统（SSO），其他系统球球SSO进行登录；
b、原本用户信息存储在Session，现在存储在Redis；
2.2、解决Cookie跨域问题上面说到了session不能共享，但是还有另外一个重要问题，Cookid不能跨域
比如说，我们请求google.com的Cookie带过去给google的服务器，而不会把google的服务器。
这就意味着，由于域名不同，用户向系统A登录后，系统A返回给浏览器的Cookie，用户再请求系统B的时候不会将系统A的Cookie带过去。
结局方案：
1、服务端将Cookie写到客户端后，客户端对Cooie进行解析，将Token解析出来，此后请求都带上Token。
2、多个域名共享Cookie，在写到客户端的时候设置Cookie的domain。
3、将Token保存在SessionStroage中（不依赖Cookie就没有跨域的问题了）
2.3、CAS原理（单点登录）如果已经将登录单独抽取成系统出来，我们还能这样玩。现在我们有两个系统，分别是www.java3y.com和 www.java4y.com，一个SSO www.sso.com
a、首先，用户想要访问系统Awww.java3y.com受限的资源(比如说购物车功能，购物车功能需要登录后才能访问)，系统Awww.java3y.com发现用户并没有登录，于是重定向到sso认证中心，并将自己的地址作为参数。请求的地址如下： www.sso.com?service=www.java3y.com
b、其次，sso认证中心发现用户未登录，将用户引导至登录页面，用户进行输入用户名和密码进行登录，用户与认证中心建立全局会话（生成一份Token，写到Cookie中，保存在浏览器上）；随后，认证中心重定向回系统A，并把Token携带过去给系统A，重定向的地址如下：www.java3y.com?token=xxxxxxx
c、此时，用户想要访问系统B www.java4y.com 受限的资源(比如说订单功能，订单功能需要登录后才能访问)，系统B www.java4y.com 发现用户并没有登录，于是重定向到sso认证中心，并将自己的地址作为参数。请求的地址如下：www.sso.com?service=www.java4y.com；
注意，因为之前用户与认证中心 www.sso.com 已经建立了全局会话（当时已经把Cookie保存到浏览器上了），所以这次系统B重定向到认证中心 www.sso.com 是可以带上Cookie的。
认证中心根据带过来的Cookie发现已经与用户建立了全局会话了，认证中心重定向回系统B，并把Token携带过去给系统B，重定向的地址如下： www.java4y.com?token=xxxxxxx
接着，系统B去sso认证中心验证这个Token是否正确，如果正确，则系统B和用户建立局部会话（创建Session）。到此，系统B和用户已经是登录状态了。
SSO认证中心就类似一个中转站。
此文章参考于网络知乎：什么是单点登录（SSO） - 知乎 (zhihu.com)
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）