SpringSecurity+JWT实现前后端分离认证和授权 第二部分：测试+流程分析

目录

前言：

测试：

分为两次请求

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

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

流程分析【重点】：

 第一个请求的流程：

具体步骤：

 第二个请求的流程：

第二个请求的前提:

具体步骤：

 对两次请求的总结：

 为什么要这样做？

---

前言：

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

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

测试：

我们测试时，采用的是postman充当客户端进行测试。

 先进行启动：

分为两次请求

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

解析如下：

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

Controller中配置的接口资源

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

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

用户名：mxy 密码：123以及所拥有的权限集合

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

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

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

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

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

流程分析【重点】：

 第一个请求的流程：

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

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

具体步骤：

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

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

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

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

我们自定义的用户为 ：用户名为mxy ，密码为123

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

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

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

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

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

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

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

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

 第二个请求的流程：

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

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

第二个请求的前提:

(1)第一个请求成功

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

设置给Authorization。格式为 ：bear+空格+JWT

具体步骤：

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

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

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

所以说：过滤器的作用就是继续解析这个JWT。

3.解析完成之后，再进行封装设置。

 对两次请求的总结：

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

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

（即是JWT），但是服务端会把JWT封装叫做access_token进行真正响应给客户端。

所以其实JWT=access_token。

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

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

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

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

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

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

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

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

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

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

 为什么要这样做？

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

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