Spring cloud微服务安全实战-4-10Zuul网关安全开发（三）

首先把地址给它

发送post请求，请求的数据就是这个entity对象。

最后返回的值要封装到TokenInfo里面

如果一切正常的话就会拿到一个响应的实体，实体里面就包含了TokenInfo

打印实体到控制台。最终返回response的body

审计日志

跟在Oauth的过滤器后面所以这里是2

模拟进来的时候插入一条数据。

授权的过滤器

授权的过滤器稍微复杂一点。要把主干逻辑写一下

判断当前的请求是不是需要身份认证，或者是需不需要做权限的判断。
生成isNeedAuth

拿到tokenInfo

之前在OAuth的Filter里面认证成功后设置了Attribute

不为空且是激活状态的

没有拿到认证的信息就写个日志，处理错误。

处理一个401的错误。

能拿到用户信息，下一步就要判断权限。如果没有权限那么就报403的错误。

生成一个随即的整数和2 取模，只有两种情况，一种是1 一种是0. 也就是有有50%可能被 403状态码拒掉。 50%的可能性会通过。

handlerError

最终要返回json的ContentType

相应的状态码

处理小bug

token的请求不做认证，token请求永远不会有tokenInfo
如果请求的URI不是以/token开头的

另外一个修复。这里是一个变量，而不是一个写死的字符串。

先不写限流，限流一会单独说。

启动服务测试

启动gateway

启动orderAPI

先去拿token

用拿到的token调用，创建订单的方法

是有一半的几率的。

故意把令牌改成错的

错误的令牌报401

不传令牌

50%的几率，调用正常。

说明我们现在写的业务逻辑时生效的，我们在网关这把权限控制了。现在就可以把订单服务里面和安全相关的逻辑去掉。包括先关的代码
这些逻辑去掉后，我们之前说的那些问题。比如说安全的逻辑和业务逻辑耦合，安全逻辑一遍导致业务逻辑重新部署，包括随着业务接节点增加，你们安全信息也在这里面。业务节点节点增加。认证服务器压力增大等等这些问题。都被解决掉了