欢迎来到尧图网

客户服务 关于我们

您的位置:首页 > 新闻 > 社会 > 问题记录(四)——拦截器“失效”?null 还是“null“?

问题记录(四)——拦截器“失效”?null 还是“null“?

2025/4/19 12:22:16 来源:https://blog.csdn.net/xiaokuer_/article/details/147285620  浏览:    关键词:问题记录(四)——拦截器“失效”?null 还是“null“?

拦截器“失效”?null 还是"null"?

问题描述

这个问题本身并不复杂,但是却是一个容易被忽略的问题。

相信大家在项目中一定实现过强制登录的逻辑吧,巧了,所要介绍的问题就出现在测试强制登录接口的过程中,具体来说:

我的项目采用 JWT令牌 + LocalStorage的方式验证和保存会话信息,当用户以无令牌的方式访问除登录页面外的其他页面时,会被后端的拦截器拦截,拦截后会设置状态码401,前端接收到401的响应后会强制跳转到登录页面。

我执行的操作,清除本地存储的token信息,然后访问非登录页面。

预期结果:当用户以无令牌的方式访问除登录页面外的其他页面时,强制跳转到登录页面。

实际结果:当用户以无令牌的方式访问除登录页面外的其他页面时,没有强制跳转到登录页面

相关代码

  • 拦截器代码
@Slf4j
@Component
public class LoginInterceptor implements HandlerInterceptor {@Overridepublic boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {//约定前端把用户的token放在header中String token = request.getHeader(Constants.HEADER_USER_TOKEN);log.info("拦截器:从header中获取token:" + token);if(token == null) {//用户未登录response.setStatus(401);return false;}Claims claim = JWTUtils.parseToken(token);if(claim == null) {//无效的tokenresponse.setStatus(401);return false;}return true;}
}
  • 前端代码
//ajaxSend:在ajax请求即将发送前执行的方法,这里的逻辑是设置header信息,确保请求携带token
$(document).ajaxSend(function(event, xhr, options) {xhr.setRequestHeader("user_token", localStorage.getItem("userToken"));
});//当后端验证失败会将状态码设置为401(即用户非登录状态),此时希望直接跳转到登录页面
$(document).ajaxError(function(event, xhr, options, exc) {if(xhr.status == 401) {location.href = "blog_login.html";}
});
  • 自定义JWT工具类中的验证方法
    public static Claims parseToken(String token) {if(!StringUtils.hasLength(token)) {return null;}try {Claims claim = Jwts.parserBuilder().setSigningKey(key).build().parseClaimsJws(token).getBody();return claim;}catch (ExpiredJwtException e) {log.error("token已过期");throw new BlogException("内部错误,请联系管理员!");}catch (Exception e) {log.error("token解析失败:" + token);throw new BlogException("内部错误,请联系管理员!");}}

我的测试以及分析:

既然没有跳转,通过前端代码可知响应的状态码不是401,按理来说,在我清除了本地的token信息的情况下向后端发送请求,拦截器应该生效呀(即应当走进token == null中设置状态码401并拦截住)。实际上,观察IDEA的控制台日志,发现的确没有拦住,代码进入了Claims claim = JWTUtils.parseToken(token);,在这一行中,触发了catch语句,并抛出了BlogException,而该异常被项目中的统一异常处理器处理,处理逻辑相关代码:

  • 统一异常处理器
    @ExceptionHandlerpublic Result blogExceptionHandler(BlogException blogException) {log.error("异常信息:", blogException.getErrMsg());return Result.fail(blogException.getErrMsg());}
  • 结果处理代码
    public static Result fail(String errMsg) {Result result = new Result();result.setErrMsg(errMsg);result.setCode(ResultCodeEnum.FAIL);return result;}

也就是说当被统一异常处理器处理后,就变为了业务异常,请求理所应当是成功了,状态码是200(与我使用fiddler抓包的结果一致),而响应的状态码是200,也就没有触发前端的跳转逻辑。

问题是:我明明清除了token,为什么拦截器的if(token == null)判断为false


解决步骤

我自己是晕了,屁颠屁颠的去找答疑老师,答疑老师一下就命中了要害:

当清除本地存储的token后,前端的如下代码有点小马脚:

//ajaxSend:在ajax请求即将发送前执行的方法,这里的逻辑是设置header信息,确保请求携带token
$(document).ajaxSend(function(event, xhr, options) {xhr.setRequestHeader("user_token", localStorage.getItem("userToken"));
});

这段代码就是在ajax请求发送前设置header信息,而依据我的代码,无论本地存储是否存在token的信息,都会为请求添加一个token的header信息,当本地不存在token信息时,localStorage.getItem("userToken")返回一个"null",也就是说,请求到后端的header中的token字段的值是一个"null"而非null(其实这么说也不太准确,可以直接看总结部分),这也就解释了为什么if(token == null)不生效。

老师给出的解决方案有两个:

  1. 修改判断条件if(token.equals("null")),这样直接就可以命中"null"
  2. 修改JWT工具类中验证token的方法,原方法验证失败直接抛出BlogException异常再被异常处理器处理,现在修改当验证失败时直接返回null而不再抛出异常

我自己也想到了一个:

  1. 修改前端代码

    localStorage.getItem返回的结果为null,直接不再在请求中设置header信息


稍加斟酌了一番,我修改了代码:体现了老师的两种思想,意味着前端保持不变:

  • 拦截器:
@Slf4j
@Component
public class LoginInterceptor implements HandlerInterceptor {@Overridepublic boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {//约定前端把用户的token放在header中String token = request.getHeader(Constants.HEADER_USER_TOKEN);log.info("拦截器:从header中获取token:" + token);// 问题就是,你前端删除token之后,传过来了一个null,字符串的null,“null”。而不是null// 所以有两种办法,// 1、校验不是字符串的“null”// 2、 校验token的有效性if(token.equals("null")) {System.out.println("字符串\"null\"判断成立");response.setStatus(401);return false;}
//        if(token == null) {
//            //用户未登录
//            response.setStatus(401);
//            return false;
//        }Claims claim = JWTUtils.parseToken(token);if(claim == null) {//无效的tokenresponse.setStatus(401);return false;}return true;}
}

代码中有一行System.out.println("字符串\"null\"判断成立");,我们将验证被判断"null"拦截成功。

  • 令牌验证方法
    public static Claims parseToken(String token) {if(!StringUtils.hasLength(token)) {return null;}try {Claims claim = Jwts.parserBuilder().setSigningKey(key).build().parseClaimsJws(token).getBody();return claim;}catch (ExpiredJwtException e) {log.error("token已过期");
//            throw new BlogException("内部错误,请联系管理员!");return null;}catch (Exception e) {log.error("token解析失败:" + token);
//            throw new BlogException("内部错误,请联系管理员!");return null;}}

再次测试:

在这里插入图片描述

发现的确被if(token.equals("null"))拦截了,页面也是成功跳转。


总结

这个错误带来的警醒

理解HttpServletRequestgetHeader(……)方法的行为:

  1. 如果请求中完全不存在该 header(即前端没有设置这个 header):
    • getHeader() 会返回 null
  2. 如果请求中存在该 header,但它的值是 null(比如前端显式设置了 xhr.setRequestHeader("user_token", null)):
    • 实际上,HTTP 协议中 header 的值 永远是字符串,没有真正的 null
    • 浏览器会自动将 null 转换成字符串 "null" 发送
    • 因此 getHeader() 会返回字符串 "null",而不是 Java 的 null

回顾前端代码的行为:它总是会设置header信息,不论是否有必要,而当本地存储中不存在目标信息时,header中的值就将是null

而这个null就被getHeader()认定为字符串。因此无法判断。

我认为这一点是最值得作为总结的。


版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com

热搜词