航天基地规划建设局网站关键词排名优化易下拉排名
拦截器“失效”？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)不生效。
老师给出的解决方案有两个：
- 修改判断条件
if(token.equals("null"))，这样直接就可以命中"null" - 修改JWT工具类中验证token的方法，原方法验证失败直接抛出
BlogException异常再被异常处理器处理，现在修改当验证失败时直接返回null而不再抛出异常
我自己也想到了一个：
-
修改前端代码
当
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"))拦截了，页面也是成功跳转。
总结
这个错误带来的警醒：
理解HttpServletRequest的getHeader(……)方法的行为：
- 如果请求中完全不存在该 header（即前端没有设置这个 header）：
getHeader()会返回null
- 如果请求中存在该 header，但它的值是
null（比如前端显式设置了xhr.setRequestHeader("user_token", null)）：- 实际上，HTTP 协议中 header 的值 永远是字符串，没有真正的
null值 - 浏览器会自动将
null转换成字符串"null"发送 - 因此
getHeader()会返回字符串"null"，而不是 Java 的null
- 实际上，HTTP 协议中 header 的值 永远是字符串，没有真正的
回顾前端代码的行为：它总是会设置header信息，不论是否有必要，而当本地存储中不存在目标信息时，header中的值就将是null，
而这个null就被getHeader()认定为字符串。因此无法判断。
我认为这一点是最值得作为总结的。
完