结果补语什么是单点登录
简单点说就是公司有A,B两个系统，我登录了A系统之后再跳转到B系统可以直接访问,⽽不需要再次登录B系统. ⼏种常见的单点登录实现⽅式
在讲解单点登录之前先讲解⼏个基本的概念:
Cookie:
Cookie是⼀段不超过4KB的⼩型⽂本数据，是保存在⽤户本地的，常见格式为:
Expires属性：设置Cookie的⽣存期
Domain属性：指定了可以访问该 Cookie 的 Web 站点或域
⽐如图中的Domain:192.168.1.72这就表⽰只能只有1.72下的请求可以使⽤这个cookie，百度什么的就不能使⽤这个cookie Path属性：定义了Web站点上可以访问该Cookie的⽬录
其他：略
Session:playsc
http请求是⽆状态的，但是我们⽇常访问系统的时候都是希望系统能记住我这个⽤户，这时候就要靠session去实现，因此session成为会话控制.但是光靠session还是⽆法实现会话控制的，还需要cookie的配置，如图所⽰:
这个JESSIONID就是保持会话的关键，它的value对应的就是该⽤户在服务器的sessionId，所以我们代码直接写HttpSession session = Session(); 才不会数据错乱.
Ps:session的存在⽅便了我们的开发，但是也在⼀定程度上增加了⿇烦,⽐如多机部署时候的seesion丢失,
重定向
⼀句话，转发是服务器⾏为，重定向是客户端⾏为.
转发和重定向都可以由java后台实现，例如:
请求转发：
重定向：
response.ContextPath + "/user")
当设置转发之后，请求会直接去转发的地址,⽽重定向的话请求会先返回客户端，然后再由客户端重新发起请求去.这⾥就隐藏了⼀个知识点，当我在后台设置了cookie然后重定向的时候，其实我重定向的请求中已经带上了我设置的cookie
(1) 假设A和B两个系统都部署在192.168.110.110服务器上
⽤户在登录了A系统之后，后台代码设置将userName和password作为cookie存⼊到⽤户的浏览器中并将cookie的domain设置为
马氏漏斗粘度计192.168.110.110,path设置为/
之后访问B系统的时候由于⼤家的Ip都是⼀样的，所以B系统能够获取到A系统设置的cookie，这是只
需要设置⼀个，在中判断⽤户是否是登录状态，如果未登录就去request中获取cookie信息，获取到之后解密然后模拟登录，这样⽤户可以⽆感知的登录到B系统.
点评：这是典型的同域单点登录实现⽅式，局限性⾮常⼤，必须要两个系统在同⼀个服务器或者⼆级域名相同的情况下才能实现,⼀般称为伪单点登录
(2) 知识库系统的单点登录实现
知识库的⽅案1的基础上增加了Nginx作为反向代理(有反向代理就有正向代理,⾃⾏查资料什么是正向代理什么是反向代理)
陈祖德虽然webaikn和webadmin部署在不同的服务器，但是对客户是⽆感知的，由于都是访问Nginx，然后再由nginx做转发代理，所以域名是同⼀个，这样cookie也是可以共享的，这⾥有⼀个点需要注意⼀下,webaikn可能是多机部署，所以nginx在做转发的时候需要设置ip_hash策略,⽬的就是保证⽤户上⼀次请求访问的哪台服务器，下⼀次还是访问那⼀台服务器，不⾄于导致session丢失的情况.
点评：解决了多机部署单点登录失效的情况，但是还是需要服务器端保存⽤户的session状态,⼀⽅⾯对于服务器端会产⽣内存压⼒，另⼀⽅⾯需要配置ip_hash导致流量不均衡，某些服务器压⼒⽐较⼤的情况.⽽且⽤户名和密码保存在cookie中也存在⼀定的安全隐患，只要被截取到⼀次请求都会造成账户被盗的情况
新标准英语第五册(3) 跨域token实现单点登录
主要步骤:
1. ⽤户登录A系统,A系统发现请求没有带token，于是重定向到单点登录认证中⼼sso系统，注意带上⽤户之前请求的url，我们后⾯就叫
oldUrl
2. Sso接收到请求，发现request的cookie中没有登录成功的令牌token，于是重定向到本系统的登录页⾯，继续带着oldUrl
3. ⽤户输⼊⽤户名和密码，提交
4. Sso验证⽤户名是否正确，不正确继续重定向到登录页⾯，如果正确，进⾏下⾯的操作:
⽣成⼀个cookie,name就叫token,value可以是任意不重复的值,uuid就⾏(注意这个cookie是浏览器和sso系统之间的)
将⽤户信息保存到redis中,key是⽣成的uuid,value就是user对象
重定向到oldUrl的地址，注意要拼接上token参数
1. A系统再次收到请求，不同的是这次有token参数,A系统根据token的值去redis验证，这⾥需要分情况讨论了
没有到：说明其他⼦系统发起了注销操作，需要重定向到sso登录页⾯
到了：有了User对象之后可以判断当前请求是否在⽤户权限表中，存在就直接放⾏，不存在返回权限不⾜，之后的请求都需要将token放到请求头信息或者url中
1. ⽤户浏览完A系统之后，准备去B系统转转，于是浏览器向B系统发起请求,B系统收到请求，发现请求没有带token，发起重定向去sso,
记得带上本次请求的oldUrl
沉默的忧伤2. 这时候其实和上⾯的第⼆步差不多，区别在于由于之前登录过sso所以这次的request中是有token的cookie的，所以sso只需要重定向到
oldUrl指向的地址就⾏，同时记得将cookie中取出来的token拼接到url中
3. B再次系统收到请求，之后的操作和步骤5是⼀样的了
点评：独⽴出单点登录认证中⼼，统⼀做权限认证操作，清晰明了
⼦系统不需要⽤session保存⽤户登录状态，减轻了服务器的负担
每次请求都是以token作为验证标准，就算请求被拦截了,⽤户的信息也不会泄露
后期做三⽅登录的时候也不需要将⽤户数据暴露给其他系统，其他系统能获取的只有token(真要做三⽅登录redis中存放的肯定是最简单的⼀些⽤户信息)
下⾯这个图取⾃哪位⼤佬我已经没有地址了，好像是百宝门
