目录

前言&＃xff1a;

测试&＃xff1a;

分为两次请求

1.第一个请求就是类似于前端请求一个登录SpringSecurity内置验证的安全登录中心

​编辑2.第二个请求就是在第一个请求成功的基础上进行请求的

流程分析【重点】&＃xff1a;

 第一个请求的流程&＃xff1a;

具体步骤&＃xff1a;

 第二个请求的流程&＃xff1a;

第二个请求的前提:

具体步骤&＃xff1a;

 对两次请求的总结&＃xff1a;

 为什么要这样做&＃xff1f;

前言&＃xff1a;

本文的测试以及流程分析&＃xff0c;都是针对于第一部分编码部分所开展的分析与总结。之后我也会发布一

个合集来方便需要学习的朋友进行查看。

测试&＃xff1a;

我们测试时&＃xff0c;采用的是postman充当客户端进行测试。

 先进行启动&＃xff1a;

分为两次请求

1.第一个请求就是类似于前端请求一个登录SpringSecurity内置验证的安全登录中心

解析如下&＃xff1a;

为的是获取到请求服务端中我们进行配置的Controller接口的权限。如果这个登录都验证不过去&＃xff0c;那么就没有权限去进行请求之后的

Controller中配置的接口资源

我们对于SpringSecurity内置的安全登录&＃xff0c;是可以进行自定义配置请求地址的&＃xff1a;我们这里配置的是/doLogin。如图&＃xff1a;在配置类中进行配置的

我们对于SpringSecurity内置的安全登录&＃xff0c;是可以进行自定义配置可成功登录该内置登录中心的成员用户信息&＃xff0c;我们这里配置的是&＃xff1a;

用户名&＃xff1a;mxy 密码&＃xff1a;123以及所拥有的权限集合

2.第二个请求就是在第一个请求成功的基础上进行请求的

第二个请求就是对后端服务器中的Controller类中的接口对应的资源进行的请求。

当第一个请求执行成功之后&＃xff0c;说明SpringSecurity登录验证已经成功 。

说明可以继续请求后端资源接口。

第一个请求之后&＃xff0c;我们就会获取一个JWT。这个JWT中就包含着我们的用户信息。然后我们就把这个JWT配置给Headers中的Authorization。

流程分析【重点】&＃xff1a;

 第一个请求的流程&＃xff1a;

首先我们使用postman进行请求我们自定义设置的SpringSecurity安全登录验证的接口doLogin

并且配置请求url的携带参数。参数为登录的用户名以及密码 &＃xff01;

具体步骤&＃xff1a;

 1.无论什么请求都会先进行经过过滤器

 2.但是由于这是security的登录验证请求&＃xff0c;其中并没有token&＃xff0c;所以我们直接通过过滤器中的解析JWT的过程。

3. 跳过过滤器之后&＃xff0c;我们会进行验证security登录。此时我们要进行判断&＃xff0c;postman发送的请求url

中携带的用户名以及密码参数是否在我们自定义的用户中

我们自定义的用户为 &＃xff1a;用户名为mxy &＃xff0c;密码为123

 4.如果登录失败&＃xff1a;会进入到我们登录失败的处理器中进行处理

 5.如果登录成功&＃xff1a;同理会跳转到登录成功处理器进行处理操作&＃xff1a;

登录成功处理器&＃xff0c;最后会把用户信息进行设置给JWT中。

然后把JWT设置给access_token。并且设置过期时间&＃xff0c;以及token的类型为bearer

 设置完成之后进行使用流进行写出 其中还使用到了转化。

 我们通过流写出响应给客户端浏览器的数据对应的格式为JSON&＃xff0c;编码为Utf-8

 6.结束之后&＃xff0c;postman(客户端)上会显示服务端响应回来的数据&＃xff0c;该数据为Json格式

这些数据就是我们上边利用PrintWriter打印流进行写出的&＃xff1a;

 第二个请求的流程&＃xff1a;

首先第二个请求就是对后端服务器中的Controller类中的接口对应的资源进行的请求。

当第一个请求执行成功之后&＃xff0c;说明SpringSecurity登录验证已经成功 说明可以继续请求后端资源接口。

第二个请求的前提:

(1)第一个请求成功

(2)携带第一个请求之后返回的access_token。这个access_token其实就是JWT。我们把这个JWT

设置给Authorization。格式为 &＃xff1a;bear&＃43;空格&＃43;JWT

具体步骤&＃xff1a;

 1.这个请求首先会被过滤器进行拦截

2.过滤器发现这个用户已经成功进行了security验证登录。那么当该用户进行这一次请求的时候&＃xff0c;

肯定会携带一个access_token。这个东西就是JWT。JWT中封装的就是我们用户的信息 &＃xff01;

所以说&＃xff1a;过滤器的作用就是继续解析这个JWT。

3.解析完成之后&＃xff0c;再进行封装设置。

 对两次请求的总结&＃xff1a;

当第一次请求时&＃xff0c;客户端postman携带想要进行登录的用户信息&＃xff0c;服务端接收请求&＃xff0c;然后进行登录

验证。登录验证成功之后&＃xff0c;也就是第一次请求之后&＃xff0c;服务端想要写出响应给客户端浏览器用户信息

&＃xff08;即是JWT&＃xff09;&＃xff0c;但是服务端会把JWT封装叫做access_token进行真正响应给客户端。

所以其实JWT&＃61;access_token。

第一次请求之后&＃xff0c;客户端具有了已经登录用户的信息 即是access_token。

当第二次请求发出时&＃xff0c;客户端postman把第一次请求获取到access_token中JWT数据进行设置给

第二次请求的Header字段中Authorization。第二次请求进行发出&＃xff0c;此时过滤器进行拦截到然后进行

对这个Authorization字段进行解析。解析得到的是用户信息&＃xff0c;此时对于第二次请求到达服务端而言

我们已经具有了该用户的信息。我们可以通过该用户的信息进行检验是否该用户已经完成了

security登录验证。如果完成了&＃xff0c;那么就可以接着进行下一步对后端服务器资源的请求。所以说&＃xff0c;

当第二次请求完成了过滤器对其JWT的解析之后&＃xff0c;后端服务器就已经获取到了这个用户对应的信

息。所以当我们进行分为后端服务器资源的时候&＃xff0c;我们会进行权限判断&＃xff0c;此时由于我们第二次请求

中的过滤之后&＃xff0c;我们已经把解析之后的JWT的数据 即是用户信息的数据设置给了

所以说&＃xff0c;我们就可以进行判断是否该服务端Controller的接口是否具有用户权限进行访问 

 为什么要这样做&＃xff1f;

因为在微服务的项目中&＃xff0c;我们可以是多个服务端。所以说&＃xff0c;我们一个用户信息保证完成一次

security登录验证之后&＃xff0c;我们就可以在所有服务端进行请求资源的权力。