認証サーバー、私には認証コードバック、そしてここで私はちょうどそれに渡されたバックの許可を移動する必要があります。私は、サーバーだったことを証明します。
最初のジャンプと第二のアプリケーションを要求するよりも、URIアドレスと同じアドレスの最初のパス、認証サーバは、このパラメータではない、とされていない場合、トークンREDIRECT_URIを要求し
、それはエラーになります。そのような要求の後、それはトークンを取得します。
フロントエンドサーバーは、フロントページにトークンを取り戻すためにかした後、
ルートディレクトリにジャンプ
バック問題を抱えているために戻って転送。autenticated値は現在、trueにautenticatedセットを置く場所がない、falseです。次に、ページはautenticatedリフレッシュではfalseです。
autenticatedコンストラクタを分析すると、偽のトーンが認証を歩いていくです。だからここでは無限ループを維持することです。
解決策は、コンストラクタで、trueにautenticatedセットを着陸した後、ある、現在の裁判官は上陸されていません。httpリクエストを送信します。私の方法を送信
/ Meの方法
tokenInfoリターンバックを置きます。私たちは、セッションの内部にtokenInfoを入れています。
認証サーバコード改革
主要是争对admin这个client加一些配置。
之前争对admin这个client只开放了一种授权模式就是password
加上authorization_code用逗号和password分隔开。
加上这种授权模式以后，就必须要填写上 web_server_redirect_uri这个字段
我们在前端 跳过去的时候 传了参数 redirect_uri这个参数 是一个路径
那么在认证服务器这边，我也需要把这个路径填进去
客户端在做跳转的时候，是一个明文的跳转。这里看到的信息都会出现在浏览器的地址栏。任何人都会看到你的clientId ,redirect_uri这个参数的值
如果我是攻击者就可以利用这个请求发一个一模一样的请求，把跳转的地址改成自己服务器的地址。
所以要在服务器端要有一份信息，在客户端跳转的时候 要对比这个信息。admin和 redirect_uri的参数和服务器端一定要能对的上。对的上才去跳转。
启动服务测试
认证服务器
网关
admin应用
订单
访问客户端应用的地址
跳转到了
在认证服务器的这里有一些配置继承了WebSecurityConfigurerAdpater
在Adpater里面 还有一些默认的安全配置
这就是说所有的请求，都必须要身份证以后才能访问 .anyRequest().authenticated()
.formLogin()当前支持表单登陆和.httpBasic登陆
这是认证服务器的默认的安全配置。
formLogin就是给你一个登陆表单。让你来登陆。
那么你登陆完成后，会再跳转到这个路径上去。
form表单的登陆 最终看到的就是这样一个页面。
点击提交后，就会勇服务器上我们写的这个去验证。用户名随便写，面是123456
验证过以后，会 再次跳转到这个路径上，在跳到登陆页面之前会把这个地址存起来。登陆成功后会再回到这个地址上去。
这个地址会做Oauth协议相关的工作。
做完以后，会发一个授权码到我们的前端服务器上
我们现在点击登陆
这还是在认证服务器上，这是一个授权的过程，
read和write这两个授权项，是在数据库内读取出来的。这里是问这两个授权向，要不要给。这个地方实际上是可以忽略掉的，默认把权限给他就行。
可以用数据库内的最后一个字段设置为true，就表示默认把所有权限都发出去。能给的权限都发出去。
这里也可以写read。这样就默认只发送read的权限。
权限都是批准，然后 点击授权 authorize。下次再有登陆行为的时候 就看不到这个页面了。是因为在数据库内已经设置为所有权限默认发送，自动把授权的过程给做了。
这行就跳回到了客户端
调回的位置就是当时发送的redirect_uri的值。进入到了前端的callback的服务里面。
callBack服务发送请求去拿token，存到session里 再跳转到我们的住额上
进到这个页面 再去发me请求
从session里获取token。
有东西就返回信息。authenticated为true 页面就显示出来 了。
页面就显示出来了。这就是整个的过程
点击按钮获取到了order的信息
获取订单的请求的控制台输出
这样整个改造完成。
结束