Spring Boot 统一功能处理

十七ing

于 2022-10-25 09:20:11 发布

阅读量326

点赞数

分类专栏： Spring 系列文章标签： spring boot java

本文链接：https://blog.csdn.net/lfm1010123/article/details/127405925

版权

Spring 系列专栏收录该内容

16 篇文章 2 订阅

订阅专栏

Spring Boot 统一功能处理

一、使用 Spring 拦截器来实现登录验证
二、统一异常处理
- 引入
- 代码实现
三、统一数据返回格式
四、为所有前端发送的 URL 地址都添加前缀 (了解)

一、使用 Spring 拦截器来实现登录验证

引入

一般来说，session 会话被我们用来作为用户的登录验证，以往我们会封装一个类，专门用于获取 session 中的用户，如果获取到了，说明用户已经登录了；反之，则没有登录。但即便封装一个类，在每个 Controller 类中，依然需要通过此封装好的类，写几行代码来继续验证用户是否已经登录了。所以，每个控制层都需要验证，这其实很不方便。

所以，就有了 Spring 拦截器的功能，它可以自定义我们想要拦截的页面。然而，我们仍然是需要 Servlet 为我们提供的 request 对象，因为它和 session 会话紧密相连。

代码实现

0-1

步骤1 自定义拦截器

① 创建一个类 (自定义拦截器)
② 让当前类实现 Spring 框架提供的 HandlerInterceptor 接口
③ 重写 preHandle 方法 (需要明确，这一步拦截器的逻辑是由我们自己实现的。)

创建 LoginInterceptor 类，作为登录拦截的作用：

// 自定义用户登录的拦截器(自定义拦截前端访问的逻辑)
@Component
public class LoginInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        HttpSession httpSession = request.getSession(false);
        if (httpSession != null && httpSession.getAttribute("userinfo") != null) {
            // 表示用户已经登录
            return true;
        }
        // 代码走到这里，说明用户还未登录
        // 在这里可以实现自己的业务逻辑，比方说让用户再次跳转到登录页面
        response.sendRedirect("login.html");
        return false;
    }
}

对 preHandle 方法进行说明：

preHandle 方法的返回值是布尔类型的，如果最终我们的代码返回 true，表示判断通过，可以访问后面的接口(控制层)；如果最终我们的代码返回 false，表示拦截器拦截成功，直接返回错误结果 (空白页面) 给前端。

实际上，这就是 AOP 的思想，拦截器在前端和后端中间插了一杠子，此时，前端访问并不直接与控制层打交道了，而是先和拦截器这个动态代理打交道，如果代理这一关过了，才能继续走后端的接口。

步骤2 添加拦截器并设置拦截规则

将步骤1 自定义的拦截器加入到框架的配置中，并且设置拦截规则。

① 创建一个类并标明 " @Configuration " 注解
② 让当前类实现 WebMvcConfigurer 接口
③ 重写 addInterceptors 方法，在方法中添加拦截规则

创建 AddConfiguration 类，添加一些拦截规则：

@Configuration
public class AddConfiguration implements WebMvcConfigurer {

    @Autowired
    private LoginInterceptor loginInterceptor;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(loginInterceptor).
                addPathPatterns("/**"). // 拦截所有 URL
                excludePathPatterns("/login"). // 不拦截登录接口
                excludePathPatterns("/register"). // 不拦截注册接口
                excludePathPatterns("/login.html"). // 不拦截登录的静态页面
                excludePathPatterns("/**/*.js"). // 不拦截所有的 js 文件
                excludePathPatterns("/**/*.css"). // 不拦截所有的 css 文件
                excludePathPatterns("/**/*.png"); // 不拦截所有的 png 图片
    }
}

拦截规则

① addPathPatterns：表示需要拦截的 URL

② excludePathPatterns：表示不需要拦截的 URL

③ **：表示拦截所有方法

④ 拦截规则不仅可以拦截 URL，也可以拦截静态 html页面，CSS、JS 文件

步骤3 创建前后端交互，用于测试

创建 UserController 类，与前端交互：

@RestController
public class UserController {

    @RequestMapping("/login")
    public String login(HttpServletRequest request, String username, String password) {
        if (StringUtils.hasLength(username) && StringUtils.hasLength(password)) {
            if (username.equals("Jack") && password.equals("123")) {
                // 登录成功后，创建 session 会话，并往会话中放入 userinfo 对象
                HttpSession httpSession = request.getSession(true);
                httpSession.setAttribute("userinfo", "userinfo");
                return "<h1> 登录成功 </h1>";
            }
        }
        return "<h1> 登录失败 </h1>";
    }
    
    @RequestMapping("/index")
    public String index() {
        return "你好，index";
    }
}

创建 login.html，以作登录失败的跳转提示：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>login 页面</title>
</head>
<body>
    <h1>请重新登录</h1>
</body>
</html>

展示效果：

在我们未登录而访问 index 路径时，就会重定向至登录页面了。

1-1

当我们登录成功后，才能正确访问被拦截的页面：

1-2

拦截器原理

拦截器在前端和后端中间插了一杠子，此时，前端访问并不直接与控制层打交道了，而是先和拦截器这个动态代理打交道。拦截器就像高铁站的安检一样，只有前端通过了安检，才能与后端控制层打交道。

此外，一个项目中可以同时配置多个拦截器。比方说，一个拦截器作为登录验证；另一个拦截器用作前端传递来的非法参数校验。( 只是两个的拦截逻辑和拦截规则不同罢了 )

1-3

二、统一异常处理

引入

假设你在浏览网页的时候，出现了下面的页面，你会有什么心情？

2-1

显然，你的第一反应不是懵懵的，就是暴躁的，反正不是快乐的。

如果我们做一个项目，未考虑到服务器端代码的异常、用户的传参异常，或是其他异常，就会出现类似于上面的错误信息。上面的 " 500 " 状态码，显然就意味着服务器端出错了。因为用户并不是程序员，他们根本看不懂后端的错误提示，甚至连前端拿到 500 这样的错误信息，也不知道后端出现了什么问题。所以，前后端如何配合，才能够将异常以一种 " 可理解 " 的方式展现在大众面前，是一件非常有意义的事情。

代码实现

① 创建一个异常类
② 为类添加 " @RestControllerAdvice " / " @ControllerAdvice " 注解
③ 为方法上添加 " @ExceptionHandler(xxx.class) " 注解

创建 MyExceptionAdvice 类，在里面实现统一异常处理

@RestControllerAdvice
public class MyExceptionAdvice {

    @ExceptionHandler(Exception.class)
    public HashMap<String, Object> ExceptionAdvice(Exception e) {
        HashMap<String, Object> result = new HashMap<>();

        result.put("status", -1);
        result.put("data", null);
        result.put("message", "发现异常：" + e.getMessage()) ;
        System.out.println("异常出现的位置：");
        e.printStackTrace();
        return result;
    }

    @ExceptionHandler(NullPointerException.class)
    public HashMap<String, Object> nullPointExceptionAdvice(NullPointerException e) {
        HashMap<String, Object> result = new HashMap<>();

        result.put("status", -1);
        result.put("data", null);
        result.put("message", "空指针异常：" + e.getMessage());
        System.out.println("异常出现的位置：");
        e.printStackTrace(); // 给后端程序员观看出错的位置
        return result; // 将异常数据打包成 json 数据，交给前端
    }
}

创建 UserController 类，用于测试：

@RestController
public class UserController {
    @RequestMapping("/index")
    public String index() {
        return "你好，index";
    }

    @RequestMapping("/error_demo")
    public String error(){
        String result = null;
        result.equals("123"); // 空指针异常
        return null;
    }

    @RequestMapping("/error_demo2")
    public String error2(){
        int a = 10 / 0; // 算数异常
        return null;
    }
}

展示结果：json 数据

1-4

IDEA 控制台打印异常日志：

1-5

注意事项：

① 异常有很多种，算数异常、数组越界、空指针异常…我们不可能将所有异常全部列举出来，所以我们可以写所有异常的父类 Exception.

② 当指定的异常和 Exception 异常同时存在，那么异常类会先执行前者。就如上面的例子，我已经指定了空指针异常，也写出了 Exception 异常，但最终执行的是空指针异常。

③ 后端不但要保证能够将简化后的异常信息返回给前端，也要知道异常的问题出现在了什么地方。所以，后端使用 " e.printStackTrace(); " 就能够在 IDEA 上很好地观察异常出现位置。

④ 前端一般只需要拿到约定的错误数据即可 (常见的 json 数据)，至于怎么将错误信息展示给用户看，是前端的职责。遇到异常，怎么修改，这才是后端的事情。

三、统一数据返回格式

① 创建一个统一数据返回格式的类
② 为类添加 " @RestControllerAdvice " / " @ControllerAdvice " 注解
③ 让类实现 ResponseBodyAdvice 接口
④ 重写 supports、beforeBodyWrite 方法

创建 MyResponseAdvice 类，在里面构造统一返回对象

@RestControllerAdvice
public class MyResponseAdvice implements ResponseBodyAdvice {
    /**
     * 如果返回 true， 表示返回数据之前对数据进行重写，也就会进入 beforeBodyWrite 方法
     * 如果返回 false，表示结果不进行任何处理，直接返回
     */
    @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("status", 1);
        result.put("data", body); // 将原先放在 body 数据的内容，现在放在了 data 之中
        result.put("message", "");
        return result;
    }
}

创建 UserController 类，用于测试：

@RestController
public class UserController {

    @RequestMapping("/login2")
    public boolean login2(HttpServletRequest request, String username, String password) {
        if (StringUtils.hasLength(username) && StringUtils.hasLength(password)) {
            if (username.equals("Jack") && password.equals("123")) {
                HttpSession httpSession = request.getSession(true);
                httpSession.setAttribute("userinfo", "userinfo");
                return true;
            }
        }
        return false;
    }
}

展示结果：

1-6

注意事项：

统一数据返回格式的优点有很多，比如以下几个：

① 方便前端程序员更好的接收和解析后端数据接口返回的数据。
② 降低前端程序员和后端程序员的沟通成本，两者按照某个格式实现就行了，因为所有接口都是这样返回的。此外，更有利于项目统一数据的维护和修改。
③ 有利于后端技术部门的统一规范的标准制定，不会出现稀奇古怪的返回内容。

但实际上，统一也就意味着不能个性化，如果前后端交互的数据是统一的，在某些特殊的场景下，不能够很好地解决、优化问题。所以，是否选择统一数据返回，还需要根据具体的业务场景决定。

四、为所有前端发送的 URL 地址都添加前缀 (了解)

@Configuration
public class AddConfiguration implements WebMvcConfigurer {

    // 为所有前端发送的 URL 地址都添加前缀
    @Override
    public void configurePathMatch(PathMatchConfigurer configurer) {
        configurer.addPathPrefix("app", c -> true);
    }
}