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

问题描述

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

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

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

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

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

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

相关代码：

• 拦截器代码

@Slf4j
@Component
public class LoginInterceptor implements HandlerInterceptor {
    @Override
    public 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) {
            //无效的token
            response.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，而该异常被项目中的统一异常处理器处理，处理逻辑相关代码：

• 统一异常处理器

    @ExceptionHandler
    public 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而不再抛出异常

我自己也想到了一个：

3. 修改前端代码

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

---

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

• 拦截器：

@Slf4j
@Component
public class LoginInterceptor implements HandlerInterceptor {
    @Override
    public 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) {
            //无效的token
            response.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"))拦截了，页面也是成功跳转。

---

总结

这个错误带来的警醒：

理解HttpServletRequest的getHeader(……)方法的行为：

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()认定为字符串。因此无法判断。

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

---

完