文章目录
- 引言
- 一、⽤户登录权限效验
- Spring 拦截器
- 拦截器实现原理
- 扩展：统⼀访问前缀添加
- 二、统⼀异常处理
- 三、统⼀数据返回格式
- 四、@ControllerAdvice 源码分析
引言
接下来是 Spring Boot 统⼀功能处理模块，是 AOP 的实战环节，要实现的课程⽬标有以下 3 个：
- 统⼀⽤户登录权限验证；
- 统⼀数据格式返回；
- 统⼀异常处理
一、⽤户登录权限效验
⽤户登录权限的发展从之前每个⽅法中⾃⼰验证⽤户登录权限，到现在统⼀的⽤户登录验证处理，它是⼀个逐渐完善和逐渐优化的过程
1.1、最初⽤户登录验证：
在每个方法里获取 session 和 session 中的用户信息，如果存在用户就认为登录成功了，否则就登录失败 ！
@RestController
@RequestMapping("/user")
public class UserController {
/**
* 某⽅法 1
*/
@RequestMapping("/m1")
public Object method(HttpServletRequest request) {
// 有 session 就获取，没有不会创建
HttpSession session = request.getSession(false);
if (session != null && session.getAttribute("userinfo") != null) {
// 说明已经登录，业务处理
return true;
} else {
// 未登录
return false;
}
}
/**
* 某⽅法 2
*/
@RequestMapping("/m2")
public Object method2(HttpServletRequest request) {
// 有 session 就获取，没有不会创建
HttpSession session = request.getSession(false);
if (session != null && session.getAttribute("userinfo") != null) {
// 说明已经登录，业务处理
return true;
} else {
// 未登录
return false;
}
}
// 其他⽅法...
}
从上述代码可以看出，每个⽅法中都有相同的⽤户登录验证权限，它的缺点是：
- 每个⽅法中都要单独写⽤户登录验证的⽅法，即使封装成公共⽅法，也⼀样要传参调⽤和在⽅法中进⾏判断。
- 添加控制器越多，调⽤⽤户登录验证的⽅法也越多，这样就增加了后期修改和维护成本
- 这些⽤户登录验证的⽅法和接下来要实现的业务⼏何没有任何关联，但每个⽅法中都要写⼀遍。所以提供⼀个公共的 AOP ⽅法来进⾏统⼀的⽤户登录权限验证迫在眉睫
1.2、Spring AOP ⽤户统⼀登录验证的问题
说到统⼀的⽤户登录验证，我们想到的第⼀个实现⽅案是 Spring AOP 前置通知或环绕通知来实现，具体实现代码如下：
@Aspect
@Component
public class UserAspect {
// 定义切点⽅法 controller 包下、⼦孙包下所有类的所有⽅法
@Pointcut("execution(* com.example.demo.controller..*.*(..))")
public void pointcut() {
}
// 前置⽅法
@Before("pointcut()")
public void doBefore() {
}
// 环绕⽅法
@Around("pointcut()")
public Object doAround(ProceedingJoinPoint joinPoint) {
Object obj = null;
System.out.println("Around ⽅法开始执⾏");
try {
// 执⾏拦截⽅法
obj = joinPoint.proceed();
} catch (Throwable throwable) {
throwable.printStackTrace();
}
System.out.println("Around ⽅法结束执⾏");
return obj;
}
}
如果要在以上 Spring AOP 的切⾯中实现⽤户登录权限效验的功能，有以下两个问题：
- 没办法获取到 HttpSession 和 Request 对象
- 实际拦截规则很复杂，使用简单的aspectJ表达式无法满足拦截需求。我们要对⼀部分⽅法进⾏拦截，⽽另⼀部分⽅法不拦截，如注册⽅法和登录⽅法是不拦截的，这样的话排除⽅法的规则很难定义，甚⾄没办法定义
那这样如何解决呢？
Spring 拦截器
1.3、Spring 拦截器
对于以上问题 Spring 中提供了具体的实现拦截器：HandlerInterceptor，拦截器的实现分为以下两个步骤：
- 创建⾃定义拦截器，实现 HandlerInterceptor 接⼝，并重写 preHandle（执⾏具体⽅法之前的预处理）⽅法。
- 将⾃定义拦截器加⼊系统的配置文件 必须实现 WebMvcConfigurer 并重写 addInterceptors ⽅法
具体实现如下：
- ⾃定义拦截器
接下来使⽤代码来实现⼀个⽤户登录的权限效验，⾃定义拦截器是⼀个普通类，具体实现代码如下：
//返回 true 表示拦截判断通过，可以访问后面的接口，如果返回 false 表示拦截未通过，直接返回结果给前端
@Component
public class LoginInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
HttpSession session = request.getSession(false);
if (session != null && session.getAttribute("userinfo") != null) {
// 表示已经登录
return true;
}
// 执行到此行代码表示未登录，未登录就跳转到登录页面
response.sendRedirect("/login.html");
return false;
}
}
注意： 返回 true，表示拦截判断通过，可以访问后面的接口。如果返回 false 表示拦截未通过，直接返回结果给前端
- 将⾃定义拦截器加⼊到系统配置
@Configuration
// 要想加入系统配置，必须实现 WebMvcConfigurer
public class AppConfig implements WebMvcConfigurer {
// 可以通过注入的方式，将自定义拦截器注入到配置中
@Autowired
private LoginInterceptor loginInterceptor;
@Override
// 重写 addInterceptors，将自定义拦截器注册进来
public void addInterceptors(InterceptorRegistry registry) {
// registry.addInterceptor( new LoginInterceptor). 也可以直接 new 一个对象
registry.addInterceptor(loginInterceptor).
addPathPatterns("/**"). // 拦截所有的 url 接口
excludePathPatterns("/user/login"). // 设置不用拦截的接口
excludePathPatterns("/user/reg").
excludePathPatterns("/login.html").
excludePathPatterns("/reg.html").
excludePathPatterns("/**/*.js").
excludePathPatterns("/**/*.css").
excludePathPatterns("/**/*.png").
excludePathPatterns("/**/*.jpg");
}
}
其中：
- addPathPatterns：表示需要拦截的 URL，“**”表示拦截任意⽅法（也就是所有⽅法）
- excludePathPatterns：表示需要排除的 URL
说明：以上拦截规则可以拦截此项⽬中的使⽤ URL，包括静态⽂件（图⽚⽂件、JS 和 CSS 等⽂件）
- 拦截器功能验证
controller 中的代码实现如下
@RestController
@RequestMapping("/user")
public class UserController {
@RequestMapping("/login")//登录
public boolean login(HttpServletRequest request, String username, String password) {
boolean result = false;
if (StringUtils.hasLength(username) && StringUtils.hasLength(password)) {
// 伪代码 不访问数据库
if (username.equals("admin") && password.equals("admin")) {
HttpSession session = request.getSession();
session.setAttribute("userinfo", "userinfomessage");
return true;
}
}
return result;
}
@RequestMapping("/reg")//注册
public int reg() {
return 1;
}
@RequestMapping("/index")//主页面
public String index() {
return "Hello,Index.";
}
}
- index 主页面在我们的拦截规则中，当我们先不登录时，即不获得 session 时，我们通过 url http://127.0.0.1:8080/user/index 直接访问看看效果：
可以看出，当我们没有登录获取 session 时，我们尝试直接访问主页面会失败，直接跳转到了登录页面，这也刚好符合我们拦截器中的实现，直接重定向到登录界面 ！！由此可见我们成功的实现了拦截，即统一登录验证：当我们没有登录，直接访问拦截的页面是访问不到的 ！
-
我们尝试先登录，将session 获取到，在访问主页面 index，效果如下：
-
上述登录成功，我们接着访问主页面 index ！！
所以即使我们的主页面index在拦截规则中，但是当拦截器中验证到你的 session 不为空，且存在用户信息时，即已经成功实现了登录。就说明该index主页面已经通过了拦截器验证(登录验证)，可以直接访问到该页面 ！
拦截器实现原理
- 有了拦截器之后，会在调⽤ Controller 之前进⾏相应的业务处理，执⾏的流程如下图所示：
- 拦截器源码分析
所有的 Controller 执⾏都会通过⼀个调度器 DispatcherServlet 来实现，这⼀点可以从 Spring Boot 控制台的打印信息看出，如下图所示：
⽽所有⽅法都会执⾏ DispatcherServlet 中的 doDispatch 调度⽅法，doDispatch 部分关键源码如下：
protected void doDispatch(HttpServletRequest request, HttpServletResponse
response) throws Exception {
HttpServletRequest processedRequest = request;
HandlerExecutionChain mappedHandler = null;
boolean multipartRequestParsed = false;
WebAsyncManager asyncManager =
WebAsyncUtils.getAsyncManager(request);
try {
try {
ModelAndView mv = null;
Object dispatchException = null;
try {
processedRequest = this.checkMultipart(request);
multipartRequestParsed = processedRequest != request;
mappedHandler = this.getHandler(processedRequest);
if (mappedHandler == null) {
this.noHandlerFound(processedRequest, response);
return;
}
HandlerAdapter ha =
this.getHandlerAdapter(mappedHandler.getHandler());
String method = request.getMethod();
boolean isGet = HttpMethod.GET.matches(method);
if (isGet || HttpMethod.HEAD.matches(method)) {
long lastModified = ha.getLastModified(request,
mappedHandler.getHandler());
if ((new ServletWebRequest(request,
response)).checkNotModified(lastModified) && isGet) {
return;
}
}
// 调⽤预处理
if (!mappedHandler.applyPreHandle(processedRequest,
response)) {
return;
}
从上述源码可以看出在开始执⾏ Controller 之前，会先调⽤ 预处理⽅法 applyPreHandle，⽽
applyPreHandle ⽅法的实现源码如下：
boolean applyPreHandle(HttpServletRequest request, HttpServletResponse
response) throws Exception {
for(int i = 0; i < this.interceptorList.size(); this.interceptorIndex
= i++) {
// 获取项⽬中使⽤的拦截器 HandlerInterceptor
HandlerInterceptor interceptor =
(HandlerInterceptor)this.interceptorList.get(i);
if (!interceptor.preHandle(request, response, this.handler)) {
this.triggerAfterCompletion(request, response,
(Exception)null);
return false;
}
}
return true;
}
从上述源码可以看出，在 applyPreHandle 中会获取所有的拦截器 HandlerInterceptor 并执⾏拦截器中的 preHandle ⽅法，这样就会咱们前⾯定义的拦截器对应上了，如下图所示：
通过上⾯的源码分析，我们可以看出，Spring 中的拦截器也是通过动态代理和环绕通知的思想实现的，⼤体的调⽤流程如下：
扩展：统⼀访问前缀添加
所有请求地址添加 api 前缀：
@Override
public void configurePathMatch(PathMatchConfigurer configurer) {
// 给所有的地址添加 api 前缀
configurer.addPathPrefix("api", c -> true);// c 表示所有的 controller
}
其中第⼆个参数是⼀个表达式，设置为 true 表示启动前缀
二、统⼀异常处理
统⼀异常处理使⽤的是 @ControllerAdvice + @ExceptionHandler 来实现的，@ControllerAdvice 表示控制器通知类，@ExceptionHandler 是异常处理器，两个结合表示当出现异常的时候执⾏某个通知，也就是执⾏某个⽅法事件，具体实现代码如下：
public class MyExceptionAdvice {
@ExceptionHandler(Exception.class)
public HashMap<String, Object> handler(Exception e) {
HashMap<String, Object> map = new HashMap<>();
map.put("data", null);
map.put("status", -1);
map.put("message","总的异常信息：" + e.getMessage());
return map;
}
}
注意：
- 控制器通知类：添加@RestControllerAdvice注解！ 在统一异常处理中，如果 controller中的方法发生了异常后能够走到该通知里面执行相应的方法，是针对于 controller 的方法增强，多了异常处理
- @RestControllerAdvice 是 @ControllerAdvice + @ResponseBody 它以 json 的格式给前端返回异常信息
- @ExceptionHandler 是异常处理器，出现异常后具体需要执行的方法事件
以上代码表示，如果 controller 中的方法出现了异常就返回给前端⼀个 HashMap 的对象，其中包含的字段如代码中定义的那样 ！！
仔细观察会发现 ！我们的异常处理器处理的所有异常的父类 Exception ，即不管出现什么异常我们都能处理！然而我们也可以针对不同的异常，返回不同的结果，如以下代码所示：
@ControllerAdvice
@ResponseBody
public class ExceptionAdvice {
@ExceptionHandler(ArithmeticException.class)
public Object ArithmeticExceptionAdvice(ArithmeticExceptione) {
HashMap<String, Object> result = new HashMap<>();
result.put("success", -1);
result.put("message", "除数为0异常：" + e.getMessage());
result.put("data", null);
return result;
}
}
上述处理就表示，我们可以只处理空指针异常，而当出现其他异常时该异常处理器就会失效 ！！
注意： 当有多个异常通知时，匹配顺序为当前类及其⼦类向上依次匹配 ，如下：
在异常通知类中将上述两个示例代码写在一起，再在 UserController 中设置⼀个除数为0异常 ！
@RequestMapping("/index")
public String index() {
int num = 10 / 0;
return "Hello,Index.";
}
访问上述方法，观察执行结果如下：
显而易见，我们是根据 ArithmeticExceptionAdvice 来处理算数异常的 ！并没有通过 Exception ！
三、统⼀数据返回格式
为什么需要统⼀数据返回格式？
-
有利于项⽬统⼀数据的维护和修改。
-
⽅便前端程序员更好的接收和解析后端数据接⼝返回的数据。
-
有利于后端技术部⻔的统⼀规范的标准制定，不会出现稀奇古怪的返回内容
-
降低前端程序员和后端程序员的沟通成本，按照某个格式实现就⾏了，因为所有接⼝都是这样返回的。
统⼀数据返回格式的实现
统⼀的数据返回格式可以添加 @ControllerAdvice 注解，表示当 controller 方法中有返回值时就会进入当这个通知类中，对返回值进行统一格式处理！ 还必须实现 ResponseBodyAdvice 接口，并重写 supports 和 beforeBodyWrite 方法，具体实现代码如下：
@ControllerAdvice
public class MyResponseAdvice implements ResponseBodyAdvice {
@Override
public boolean supports(MethodParameter returnType, Class converterType) {
return true;
}
@Override
public Object beforeBodyWrite(Object body, MethodParameter returnType, MediaType selectedContentType, Class selectedConverterType, ServerHttpRequest request, ServerHttpResponse response) {
HashMap<String, Object> result = new HashMap<>();
result.put("state", 1);
result.put("data", body);
result.put("msg", null);
return result;
}
}
注意：
- 重写 supports 方法时，若返回 true 表示返回数据之前对数据进行重写，也就是会进入 beforeBodyWrite 方法，而返回 false 表示对返回数据不做任何处理直接返回
- 重写 beforeBodyWrite 方法是对返回值的统一格式的具体处理，其中的参数 body 就是返回值
验证结果如下：
我们访问前面代码中的注册页面，其返回值为 1
@RequestMapping("/reg")
public int reg() {
return 1;
}
当不做统一数据返回格式处理时
以下为加上统一返回数据格式后：
四、@ControllerAdvice 源码分析
前面我们了解到被@ControllerAdvice修饰的类为 controller 通知类，当 controller 中的方法发生了相应的事件，就会进入该通知类中执行对应的方法，就比如前面的统一异常处理和统一返回格式处理
通过对 @ControllerAdvice 源码的分析我们可以知道上⾯统⼀异常和统⼀数据返回的具体执⾏流程，源码如下：
从上述源码可以看出 @ControllerAdvice 派⽣于 @Component 组件，⽽所有组件初始化都会调⽤
InitializingBean 接⼝。
所以接下来我们来看 InitializingBean 有哪些实现类？在查询的过程中我们发现了，其中 Spring MVC中的实现⼦类是 RequestMappingHandlerAdapter，它⾥⾯有⼀个⽅法 afterPropertiesSet() ⽅法，表示所有的参数设置完成之后执⾏的⽅法，如下图所示：
⽽这个⽅法中有⼀个 initControllerAdviceCache ⽅法，查询此⽅法的源码如下：
我们发现这个⽅法在执⾏时会查找所有使⽤ @ControllerAdvice 的类，这些类会被保存在容器中，一但发⽣某个事件时，调⽤相应的 Advice ⽅法，⽐如返回数据前调⽤统⼀数据封装，⽐如发⽣异常是调⽤异常的Advice ⽅法实现
