拦截器“失效”?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()
认定为字符串。因此无法判断。
我认为这一点是最值得作为总结的。
完