springboot 404 重复经过拦截器以及解决方法

小灰灰 2022-09-11 09:17 137阅读 0赞

之前没注意springboot 404 会经过两次拦截器  
我在拦截器做了token判断

@Override
        public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
            //返回数据格式
            response.setContentType("application/json;charset=UTF-8");
            //获取请求头的token
    //        System.out.println(request.getRequestURI());
    //        System.out.println((Integer) request.getAttribute(RequestDispatcher.ERROR_STATUS_CODE));
            String token = request.getHeader("token");
    
                if (!StringUtils.hasText(token) || Objects.isNull(stringRedisTemplate.opsForValue().get("connect_" + token))) {
                    throw new CustomException(TOKEN_ERROR);
                } else {
                    return true;
                }
        }

在拦截器上我也做了处理，对异常重定向的/error也做了拦截放行

//添加拦截器
        @Override
        public void addInterceptors(InterceptorRegistry registry) {
            registry.addInterceptor(getLoginInterceptor())
                    .addPathPatterns("/**")
                    .excludePathPatterns("/account/login","/outside/**","/error");
    
        }

当时我以为会返回404的页面但是返回的却是500

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oiR5piv55yf55qE6I-cKOOEkm_jhJIp_size_20_color_FFFFFF_t_70_g_se_x_16]  
明明放行了/error，但是他还是经过了拦截器

打开控制板输出requesturi

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oiR5piv55yf55qE6I-cKOOEkm_jhJIp_size_20_color_FFFFFF_t_70_g_se_x_16 1]  
打印出来的是当前地址  
是不是/error不走呢，然后我不放行/error

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oiR5piv55yf55qE6I-cKOOEkm_jhJIp_size_20_color_FFFFFF_t_70_g_se_x_16 2]  
发现第一次走的是原地址，第二次走的是/error

这就头痛了，如果只放行/error,会走原路径那我返回500的页面，明明404却返回500,这有点不妥，但是我也不可能在过滤器上判断uri是否符合程序所写的uri,毕竟接口会不断累加的。

最终我发现一个解决方法

配置文件yml加上这一段话（后来发现这个方式不妥，最底下补上正确的解决方式）

spring:
      web:
        resources:
          add-mappings: false

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oiR5piv55yf55qE6I-cKOOEkm_jhJIp_size_20_color_FFFFFF_t_70_g_se_x_16 3]  
这回正常了，因为只走一次/error,而我放行了error就没打印

为啥加上这段配置就不会走原地址，其实我没太明白，这跟静态资源有啥关系，有待研究

后续：  
自己打了断点之后发现是在DispatchServlet里面的getHandler有所不同

// Determine handler for the current request.
    				mappedHandler = getHandler(processedRequest);
    				if (mappedHandler == null) {
    					noHandlerFound(processedRequest, response);
    					return;
    				}

/**
    	 * Return the HandlerExecutionChain for this request.
    	 * <p>Tries all handler mappings in order.
    	 * @param request current HTTP request
    	 * @return the HandlerExecutionChain, or {@code null} if no handler could be found
    	 */
    	@Nullable
    	protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
    		if (this.handlerMappings != null) {
    			for (HandlerMapping mapping : this.handlerMappings) {
    				HandlerExecutionChain handler = mapping.getHandler(request);
    				if (handler != null) {
    					return handler;
    				}
    			}
    		}
    		return null;
    	}

如果没有配置add-mappings: false  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oiR5piv55yf55qE6I-cKOOEkm_jhJIp_size_20_color_FFFFFF_t_70_g_se_x_16 4]  
多对一个静态资源的handlermapping  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oiR5piv55yf55qE6I-cKOOEkm_jhJIp_size_14_color_FFFFFF_t_70_g_se_x_16]  
然后给你匹配上  
![在这里插入图片描述][8d0a4eb84d0a46a390911a11fa836418.png]

而配置了add-mappings: false  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oiR5piv55yf55qE6I-cKOOEkm_jhJIp_size_20_color_FFFFFF_t_70_g_se_x_16 5]  
就直接给你走404了，不会过两次拦截起了  
![在这里插入图片描述][3f321676200040b981865a1325861ee7.png]  
**过了几天回顾了，这个问题  
发现这种处理方式不妥，如果关闭映射会导致访问不了静态资源**  
其实resourcesHandlerMapping默认匹配是/\*\*，只要修改默认匹配规则就能避免走拦截器

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oiR5piv55yf55qE6I-cKOOEkm_jhJIp_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]

正确解决方式为

spring:
      mvc:
        static-path-pattern: /static/**

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oiR5piv55yf55qE6I-cKOOEkm_jhJIp_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/3bea44d1502343d5b08e2629d587b6b1.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oiR5piv55yf55qE6I-cKOOEkm_jhJIp_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/878fc569c50f48b48a369f3bcbc0ba56.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oiR5piv55yf55qE6I-cKOOEkm_jhJIp_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/f080eb20fca148779ce6c65e72a720a0.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oiR5piv55yf55qE6I-cKOOEkm_jhJIp_size_20_color_FFFFFF_t_70_g_se_x_16 3]: /images/20220828/a4adc8446ef249139b49e7b149d9bb92.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oiR5piv55yf55qE6I-cKOOEkm_jhJIp_size_20_color_FFFFFF_t_70_g_se_x_16 4]: /images/20220828/94147e1edd5146a197991fce55e2e1bd.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oiR5piv55yf55qE6I-cKOOEkm_jhJIp_size_14_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/ca84867a9b3b42e0aefa33240ddbd800.png
[8d0a4eb84d0a46a390911a11fa836418.png]: /images/20220828/87b1efc3a63b4df99b22f96b2d6daf43.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oiR5piv55yf55qE6I-cKOOEkm_jhJIp_size_20_color_FFFFFF_t_70_g_se_x_16 5]: /images/20220828/bfbf1846c34e478e906c52233dc21780.png
[3f321676200040b981865a1325861ee7.png]: /images/20220828/67073cddddc541d5889bb36e95dd3944.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5oiR5piv55yf55qE6I-cKOOEkm_jhJIp_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]: /images/20220828/77035f0d08c8481780d48367465a2c1d.png