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

Posted 2021-03-24 青春是课桌下风干的鼻屎，是借了不还的直尺。

首先把地址给它


发送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%的几率，调用正常。

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

去掉订单服务安全的相关代码

首先去掉Oauth2的依赖。

所有和安全相关的代码都删掉。


当前用户的信息使用这个注解来拿到的。现在这个注解依赖都被删掉了 那么如何拿到当前用户的信息

比如我想拿到用户名，那么用户信息从哪里来。从RequestHeader里面


在网关授权往下走的之前 ，设置header。这里也可以传json对象，

启动测试

启动oderApi和网关

还是调这个创建订单的服务，要多试几次，因为是50%的几率是200




来看一下orderAPI的日志

拿到用户信息。但是用户信息是放在请求头里传的是一个明文

后面还会讲一些方案，在服务之间传递用户信息。

 

结束