🎉🎉🎉点进来你就是我的人了
博主主页：🙈🙈🙈戳一戳,欢迎大佬指点!

欢迎志同道合的朋友一起加油喔🤺🤺🤺

目录

前言

1. Spring 拦截器

1.1 自定义拦截器

1.2 将自定义拦截器加入到系统配置中

1.3 拦截器实现原理

统一访问前缀添加 (扩展)

2. 统一异常的处理 （@ControllerAdvice 和 @ExceptionHandler）

3.统一数据返回格式

实现统一数据返回格式的功能

特殊情况，返回String类型

解决方案

前言

在学习了SpringAOP的原生操作后，我就立即着手想着去写一个统一处理用户登陆权限验证的功能。可能大多数小伙伴的想法和我一致，直接使用SpringAOP的前置通知方法或者环绕通知方法来实现不就行了吗？但是在真正使用原生SpringAOP对该功能进行实现时，我遇到了以下几个问题：

  • 首先是要验证用户的登陆状态，就要先获取到内存中的session对象，但是通过前置或者环绕通知的方式时很难拿到请求对象的，也就很难拿到session对象进行判断。
  • 其次是与我们用户相关的控制器中并非所有方法都要进行拦截判断（像登录、注册方法），那这样就大大增加了通过原生SpringAOP的切点表达式配置拦截规则的难度

那该怎么解决上述的问题呢？——更好的解决办法就是使用Spring拦截器~

1. Spring 拦截器

对于上述问题, Spring 提供的拦截器就可以很好地解决.

Spring拦截器与传统AOP的关系可以类比于Servlet与Spring之间的关系。拦截器在某种程度上包含了传统AOP的概念,同时内置了对HTTP请求和响应对象的支持,以提供更方便的功能。

一个项目里面实现统一用户验证登录的处理, 一般有三种解决方案:

  1. 使用传统的 AOP,
  2. 使用拦截器,
  3. 使用过滤器.

既然有三种解决方案, 为什么要选择使用拦截器呢 ?

  •  对于传统的 AOP, 功能比较简单, 写法过于复杂, 所以不使用.
  •  对于过滤器 (web容器提供的), 因为它的执行时机太靠前了, Spring 框架还没初始化, 也就是说触发过滤器的时候, request, response 对象还没有实例化. 所以过滤器用的也比较少. 

🍁实现拦截器的两大步骤

  1. 创建自定义拦截器, 实现 HandlerInterceptor 接口并重写preHandle (执行方法前的预处理) 方法.

  2. 将自定义拦截器加入 WebMvcConfigurer 的 addInterceptors 方法中. 【配置拦截规则】

  • a) 给当前的类添加 @Configuration 注解
  • b) 实现WebMvcConfigurer 接口
  • c) 重写 addInterceptors 方法

1.1 自定义拦截器

/**
 * 拦截器
 */
@Component
public class LoginInterceptor implements HandlerInterceptor {
    //调用目标方法执行之前的方法
    //此方法返回的是boolean 类型的值
    //如果返回的true 表示(拦截器)验证成功, 继续走后续的流程,执行目标方法
    //如果返回false, 表示拦截器执行失败, 验证为通过, 后续的流程和目标方法就不要执行了
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        //用户登录判断业务
        HttpSession session = request.getSession(false);
        if(session != null && session.getAttribute("session_userinfo") != null) {
            //用户已经登录
            return true;
        }
        //登录失败,页面返回一个错误状态码
        response.setStatus(401);
        return false;
    }
}

自定义的拦截器是一个普通的类, 如果返回 true, 才会继续执行后续代码.

1.2 将自定义拦截器加入到系统配置中

前面写的自定义拦截器, 只是一个普通的类, 需要把它加入到系统配置中, 并配置拦截规则, 才是一个真正有用的拦截器.

@Configuration
public class myConfig implements WebMvcConfigurer {
    @Autowired //属性注入(注入loginInterceptor对象)
    private LoginInterceptor loginInterceptor;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(loginInterceptor)
                .addPathPatterns("/**") //拦截所有url
                .excludePathPatterns("/user/login")  //排除url /user/login 登录不拦截
                .excludePathPatterns("/user/reg")     //注册不拦截
                .excludePathPatterns("/image/**")  //排除image 文件夹下的所有文件
        ;
    }
}

1. addInterceptor 方法的作用 : 将自定义拦截器添加到系统配置中.
2. addPathPatterns : 表示需要拦截的 URL.
3. excludePathPatterns : 表示不拦截, 需要排除的 URL.
4. 拦截器不仅可以拦截方法, 还可以拦截静态文件 (.png, .js, .css) 

咱们定义个UserController，用于验证我们自定义拦截器的功能：

@RestController
@RequestMapping("/user")
public class UserController {
    @RequestMapping("/login")
    public String login() {
        return "登录成功";
    }
    @RequestMapping("/reg")
    public String reg() {
        return "注册成功";
    }
    @RequestMapping("/index")
    public String index() {
        return "其他方法";
    }
}

前两个步骤我们已经做好了准备工作, 并配置好了拦截规则, 规定除了登录和注册功能不拦截外, 拦截其他所有 URL (getInfo). 下面来进行验证一下拦截器是否生效.

 通过浏览器显示结果和抓包结果来看, 我们自定义的拦截器确实拦截了 index() 方法, 并且设置了状态码 401, 这也符合我们的预期. 

1.3 拦截器实现原理

有了拦截器之后，会在调用Controller之前进行相应的业务处理，流程如下：

  • 首先我们要知道 Controller 的执行都会通过一个调度器 (DispatcherServlet) 来实现.
  • 随便访问 controller 中的一个方法就能在控制台的打印信息就能看到, 这个可以类比到线程的调度上.

 然后所有 Controller 中方法都会执行 DispatcherServlet 中的调度方法 doDispatch().

我们通过分析源码, 发现源码中的这两个主要步骤.预处理的过程就 和 前边代码 LoginInterceptor 拦截器做的事情差不多,判断拦截的方法是否符合要求, 如果符合要求, 就返回 true,然后继续执行后续业务代码, 否则, 后面的代码都不执行.

 进入 applyPreHandle() 方法继续分析:

我们发现源码中就是通过遍历存放拦截器的 List, 然后不断判断每一个拦截器是否都返回 true 了, 但凡其中有一个拦截器返回 false, 后面的拦截器都不要走了, 并且后面的业务代码也不执行了. 看到这, 我们恍然大悟了.

通过前面的分析， 我们就能发现 Spring 中的拦截器其实就是封装了传统的 AOP , 它也是通过 动态代理的和环绕通知的思想来实现的        

统一访问前缀添加 (扩展)

如果我们想要在所有的请求地址前面加一个地址，我们可以进行以下操作，我们以加前缀api为例

@Configuration
public class MyConfig implements WebMvcConfigurer {
     // 所有的接口添加 api 前缀
     @Override
     public void configurePathMatch(PathMatchConfigurer configurer) {
         configurer.addPathPrefix("api", c -> true);
     }
}

我们addPathPrefix的第二个参数是一个表达式，设置为true表示启动前缀

 在浏览器输入url,测试结果如下:

2. 统一异常的处理 （@ControllerAdvice 和 @ExceptionHandler）

为什么要统一异常的处理呢 ??

    就拿用户在银行取钱这件事来说, 如果用户在办理业务的时候, 后端程序报错了, 它不返回任何信息, 或者它返回的信息不统一, 这都会让前端程序猿不知道咋办, 他不知道咋办, 那么就无法给用户提供相应的提示. 此时用户见程序没反应, 他自己也会怀疑是自己没点到, 还是程序出 bug 了. 所以需要进行统一异常的处理. 

实现统一异常的处理是需要两个注解来实现的:

  • @ControllerAdvice : 定义一个全局异常处理类，用于处理在Controller层中抛出的各种异常，并对这些异常进行统一的处理。使用@ControllerAdvice注解可以将异常处理逻辑从Controller中解耦，提高代码复用性。
  • @ExceptionHandler : 定义异常处理方法,使用@ExceptionHandler，可以根据不同类型异常进行处理

二者结合表示, 当出现异常的时候执行某个通知 (执行某个方法事件)

1.建立统一异常处理类，并加入@ControllerAdvice注解

@ControllerAdvice  //表示这个类将被用于全局的异常处理
@ResponseBody      //表示该类返回的是json数据
public class MyExceptionAdvice {
}

2.定义异常处理方法，使用@ExceptionHandler，可以根据不同类型异常进行处理
我们来进行一个空指针异常处理：

@ControllerAdvice  //表示这个类将被用于全局的异常处理
@ResponseBody      //表示该类返回的是json数据
public class MyExceptionAdvice {

    //这个注解表示当应用程序中发生NullPointerException时，会调用此方法进行处理
    @ExceptionHandler(NullPointerException.class)
    //这个方法返回一个HashMap，其中包含了异常处理的结果。结果以键值对的形式存储，键是字符串，值是Object对象。
    public HashMap<String,Object> doNullPointerException(NullPointerException e) {
        HashMap<String ,Object> result = new HashMap<>();
        result.put("code",-1);   //"code"：异常的状态码，这里是-1，表示发生了错误
        //"msg"：异常的信息，这里添加了"空指针"的前缀，并附加上异常的具体信息（e.getMessage()获取异常的信息）。
        result.put("msg","空指针" + e.getMessage());
        //data"：这里设置为null，表示没有返回的数据。
        result.put("data", null);
        return result;
    }
}

定义一个UserController 类：

@RestController  //它结合了@Controller和@ResponseBody两个注解的功能。
//这个类级别的注解指定了这个类处理的所有请求的URL路径的公共部分
@RequestMapping("/user")
public class UserController {

    @RequestMapping("/login")
    public int login() {
        Object obj = null;
        //因为obj是null，所以当调用hashCode方法时，会抛出NullPointerException。
        System.out.println(obj.hashCode());
        return 1;
    }
}

我们再来访问login，看是什么情况：

 为了看出区别,我们来做两个测试：
1.首先我们去掉@ControllerAdvice注解

  •  我们发现直接报了500的错误信息了

2.如果不是空指针异常,而是算术异常呢

  •  我们发现同样还是报了500的错误信息,因为我们统一异常处理只处理了空指针异常

  • 这种情况，我们需要再写一个算术处理异常的处理类，我们可以直接使用所有异常类的父类Exception进行异常处理，这样所有的异常都能处理到了
    @ExceptionHandler(Exception.class)
    public HashMap<String,Object> doException(Exception e) {
        HashMap<String ,Object> result = new HashMap<>();
        result.put("code",-1);   //"code"：异常的状态码，这里是-1，表示发生了错误
        //"msg"：异常的信息，这里添加了"空指针"的前缀，并附加上异常的具体信息（e.getMessage()获取异常的信息）。
        result.put("msg","Exception" + e.getMessage());
        //data"：这里设置为null，表示没有返回的数据。
        result.put("data", null);
        return result;
    }
  • 我们再来进行测试：

3.统一数据返回格式

为什么需要进行统一数据返回格式：

  1. 方便前端程序员更好的接收和解析后端数据接口返回的数据
  2. 降低前端程序员和后端程序员的沟通成本，按照某个格式进行
  3. 有利于项目统一数据的维护和修改
  4. 后端的统一规范的标准制定

实现统一数据返回格式的功能

实现步骤可以分为以下两步：

  •     自定义统一数据返回处理类，标注上@ControllerAdvice注解同时实现ResponseBodyAdvice接口。
  •     重写接口中的 supports方法和beforeBodyWrite方法 并在该方法中进行统一数据格式的处理。
     

实现代码如下：

  • supports决定是否执行beforeBodyWrite(数据重写)，返回true表示重写，false表示不重写
  • 我们这里假设标准的数据格式是HashMap
//定义的全局响应体建议（Response Body Advice）。
//其作用是在返回数据到客户端之前，对返回的数据进行处理或修改
@ControllerAdvice
public class ResponseAdvice implements ResponseBodyAdvice {

    //是否执行 beforeBodyWrite 方法,true = 执行, 重写返回结果
    @Override
    //supports方法，用于决定是否对返回的数据进行处理
    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) {
        //Hash<String, Object> -> code,msg,data
        if(body instanceof HashMap) {
            return body;
        }
        //重写返回结果, 让其返回一个统一的数据格式
        HashMap<String, Object> result = new HashMap<>();
        result.put("code", 200);
        result.put("data", body);
        result.put("msg", "");
        return result;
    }
}

我们写一下Contoller，试着返回两组数据：

@RestController
@RequestMapping("/user")
public class UserController { 
}

1.HashMap格式数据：

@RequestMapping("/reg")
public HashMap<String, Object> reg() {
    HashMap<String, Object> result = new HashMap<>();
    result.put("code", 200);
    result.put("msg", "");
    result.put("data", 1);
    return result;
}

 2.返回其他格式数据：

@RequestMapping("/login1")
public int login1() {
    return 1;
}

 我们可以发现即使我们在Controller层返回的不是标准格式的数据，也会进行重写。

特殊情况，返回String类型：

@RequestMapping("/sayHi")
public String sayHi() {
    return "say hi";
}

 这里报了类型转换异常，HashMap不能转换为String，为什么会出现这个问题呢，我们返回String会进行三个步骤：

  1. 方法返回String
  2. 统一数据格式返回的是 -> String 转为 HashMap
  3. 将HashMap转换为application/json字符串给前端

那么问题到底出现在哪一步呢?答案是我们在进行类型转换时出错了

  • 对于String 类型的数据 -> 会使用 StringHttpMessageConverter 这个转换器 进行类型转换(由于这个转换器 无法将HashMap转换为String，所以会报错)
  • 对于非String 类型的数据 ->会使用 HttpMessageConverter 这个转换器 进行类型转换
     

解决方案:

1. 将 StringHttpMessageConverter 转换器去掉,那么在进行类型转换的时候就会使用 HttpMessageConverter  这个转换器了

@Configuration
public class MyConfig implements WebMvcConfigurer {
    @Override
    //configureMessageConverters 方法使用 removeIf 方法删除了所有 StringHttpMessageConverter 的实例。
    // 这样，Spring MVC 就不会再使用 StringHttpMessageConverter 来处理 String 类型的数据了。
    public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
        converters.removeIf(converter -> converter instanceof StringHttpMessageConverter);
    }
}

 2.在统一数据重写时，单独处理String类型，直接让其返回一个json格式的字符串，而不是HashMap

    //返回数据之前进行数据重写
    @SneakyThrows
    @Override
    public Object beforeBodyWrite(Object body, MethodParameter returnType, MediaType selectedContentType, Class selectedConverterType, ServerHttpRequest request, ServerHttpResponse response) {
        if(body instanceof HashMap) {
            return body;
        }
        //重写返回结果, 让其返回一个统一的数据格式
        HashMap<String, Object> result = new HashMap<>();
        result.put("code", 200);
        result.put("data", body);
        result.put("msg", "");
        if(body instanceof String) {
            //将String类型的字符串转换成json格式的字符串返回
            return objectMapper.writeValueAsString(result);
        }
        return result;
    }
}

今天的内容到处就结束了! 如果你觉得这篇文章有价值，或者你喜欢它，那么请点赞并分享给你的朋友。你的支持是我创作更多有用内容的动力，感谢你的阅读和支持。祝你有个美好的一天！"

# spring # java # 后端
Logo
重庆城市开发者社区

长江两岸老火锅，共聚山城开发者！We Want You！

更多推荐

cover

【2023 CSDN年度报告】2023年属于哪种创作风格？一起来测！

avatar 重庆城市开发者社区
cover

Claude 3 大模型再度点燃 AI 战火，性能和速度全面超越 GPT-4

avatar 重庆城市开发者社区
cover

OpenAI承认ChatGPT变懒惰，正在修复该问题

avatar 重庆城市开发者社区