Spring cloud微服务安全实战-5-12实现基于token的SSO（2）

我只要把这个meFilter放在AuthorizationFilter后面就可以了。
authorizationFilter的排序是3

MeFilter设置为4 就可以了。

拿到了username直接返回回来

启动服务测试

启动网关

认证

现在在服务器的session上不再存任何东西了
首先登陆

一直惦记get order info。accessToken失效了 就会调用refresh_token刷一下
下面就是refresh_token失效了。

跳到认证服务器重新，去认证了。然后回调，然后又到了主页上。

惦记确定后，可以继续获取到order 的信息

一直到认证服务器上session失效。刷新令牌也失效了。才会让用户去输入用户名和密码

退出

点击退出后，还是在当前的这个页面上。

因为现在登录是由于cookies决定的，refreshToken失效了才会真正出现登录的界面

angular操作cookie需要操作一个插件

安装 ngx-cookie

app.modules.ts内引入cookieService

在provider里面加上，加载providers里面才能在自己的代码里面依赖注入。

app.component.ts

通过构造函数注入 CookieService

删除cookie

测试

跳到了登陆页

总结

cookie和session方案的区别，以前是存在客户端的session里面的，现在是存在浏览器里面的
之前存session，在客户端的服务器上一段session失效。用户就需要到认证服务器上做一次认证，
现在基于cookie的这个方案。当浏览器的refresh_token失效才需要去认证服务器做认证。
不管是哪种方案，认证服务器都会有用户的session，只不过第一种方案要保证认证服务器要保证有效时间很长的一个session这样前端服务器的session失效后，它到认证服务器上才不需要反复的去登陆。而能一直做sso，哪个客户端失效后，认证服务器都会认，。

cookie的方案，不需要认证服务器存放时间很长的session，因为决定客户端能不能访问服务的不是session的有效期，而是refresh_token的有效期。只要你refresh_token有效，就能一直访问其他的服务。

session的优点

使用https保证cookie的传递。包括cookie本身的信息的安全。放在cookie里面的accesstoken一般不会给他很长的有效期。一般是1小时或者2小时。一旦被人窃取也很快就会失效掉。现在我们子啊浏览器里面还是存的一个无异议的串

存在客户端浏览器里面的东西 没法随时删掉。存在服务器的session我们可以随时让它失效掉。

结束