首先把地址给它
发送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的日志
拿到用户信息。但是用户信息是放在请求头里传的是一个明文
后面还会讲一些方案，在服务之间传递用户信息。