解决：spring security 登录页停留时间过长 跳转至 403页面

前言：最近的项目中用到了springsecurity组件，说句显low的话：我刚开始都不知道用了security好不勒，提了bug，在改的过程中，遇到了一些问题，找同事交流，才知道是用的security组件。  这个bug，真的是一波三折：复现它就是个问题，然后我又把403改成了404，后来干脆登录不进去主站，最后，这个bug，被消灭在本宝宝的代码中，哈哈哈哈哈！

问题所在：token 过期

一、关于问题的想法

1，我在想是不是写的登录逻辑有问题，用代码控制住了当前登录页的相关缓存问题，一路跟代码。 好吧，有些工程没权限就不说了，后来同事告诉我应该没又跳转到逻辑，就死掉了。 我在登录页发现了那个 security的标记（当时根本不知道那是个啥，傻X一个），查了查，再跟同事了解了具体情况，果断放弃对逻辑的怀疑，因为我们没有用代码控制缓存失效之类的

2，既然不是用户代码的问题，那就是组件机制的问题呗。 本宝宝立马翻了spring security的文档，里面真的提到了超时的概念。 并提出了集中解决方案，链接地址如下：https://docs.spring.io/spring-security/site/docs/4.1.3.RELEASE/reference/htmlsingle/#csrf-timeouts好吧，里面提到了通过使用JS函数，在表单提交前获取到一个token值（通过使用spring提供的CsrfTokenArgumentResolver）然而本宝宝并没有在这时候干掉这个不能算是ｂｕｇ的被提出的ｂｕｇ．也提到自定义处理相关异常的建议。不过本宝宝一向都不是安分守己的人，好不容易整出一个bug，不折腾会儿，会遭天谴的，以下就是本宝宝验证演算的方案示例：

a：本来就是spring security的一种安全保护机制，不算bug，去跟测试和产品协商，忽略它——哈哈，当然这是下下策，虽然最为省事儿，但我预估99%会死

b：既然是停留时间过长才产生的问题，那我想办法，让用户不管在什么时候点击登录，就跟他刚刚输入完账户信息一样。 所以我就想到了：<METAHTTP-EQUIV="REFRESH"CONTENT="csrf_timeout_in_seconds"> 然而，在我的案例里面，并没有用啊，忧伤。

c：使用token注册机，弄出一个不过时的，给登录页面使用——哈哈，我想的挺好的。 再不行了，我找到关于这个token过期时间的代码，改掉它——果然一副写代码到死的精神

d：惹急了我，我把这个csrf的token验证功能关掉——简单又粗暴吧，嘿嘿——当然，这是决定不能干的事儿，虽然可以解决我那个bug

e：总之是出了异常，系统才会拦截到，然后跳转到了指定的403页面，那我就在它跳转到403页面之前，截住这个异常，然后由我自定义处理

f：这一条其实和第 d 条类似，我既然不能关掉所有的验证，那我关掉登录页的验证总行吧，登录页校验的本来就不是这个页面，而是用户的权限。谁都可以进入到登录页，不是吗，嘿嘿。 然后，本宝宝改写了拦截器，对登录页的请求放行了。 ——然而，可能是人品有问题，我竟然没法儿正常登录了，忧伤。肯定是哪儿被我写错了。

其实我想法可多了，总有一个能干掉这个bug，在几次忧伤之后，我选了自定义异常拦截这种方案，这条线的思路是：断点，看看它在跳转到403之前，到底拦截到了什么异常；找到异常，我自定义拦截，并做出我想要系统做出的反应

二、关键代码

自定义异常处理：

import org.springframework.security.access.AccessDeniedException;
import org.springframework.security.web.access.AccessDeniedHandlerImpl;
import org.springframework.security.web.csrf.MissingCsrfTokenException;
import org.springframework.security.web.savedrequest.HttpSessionRequestCache;
import org.springframework.security.web.savedrequest.RequestCache;import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import java.io.IOException;/**
* @author 何红霞~Angelina
*/
public class MissingCsrfTokenAccessDeniedHandler extends AccessDeniedHandlerImpl {
private RequestCache requestCache = new HttpSessionRequestCache();
private String loginPage = "/login"; @Override
public void handle(HttpServletRequest req, HttpServletResponse res, AccessDeniedException exception) throws IOException, ServletException {
if (exception instanceof MissingCsrfTokenException && isSessionInvalid(req)) {
requestCache.saveRequest(req, res);
req.getRequestDispatcher(loginPage).forward(req, res); }
super.handle(req, res, exception);
} private boolean isSessionInvalid(HttpServletRequest req) {
try {
HttpSession session = req.getSession(false);
return session == null || !req.isRequestedSessionIdValid();
}
catch (IllegalStateException ex) {
return true;
}
}}

好吧，其实这里又闹了一个笑话。 我最开始，把转发搞成重定向了，我靠，之前是token丢失，现在是整个参数都没了，想掐死自己的心都有了。 果真是久了不写基础代码，手生啊！

安全配置：

@Bean
public AccessDeniedHandler getAccessDeniedHandler() {
return new MissingCsrfTokenAccessDeniedHandler();
}

http.exceptionHandling().accessDeniedHandler(getAccessDeniedHandler());

三、总结

按照上面的方法做，问题解决了。 反正目前我自测是没毛病了，有问题再说吧，哈哈哈哈哈。

其实这之中发生了几个插曲，我觉得可以分享一下：

1，最开始是跳转到403页面，结果我一通改，403是不跳了，但跳404了。 这时候，你怎么想问题？  反正我想的是：我既然能把403改成跳到404，我就一定能让它跳转到我想要让它去的地方，我离成功只差最后一点了。  有时候，最恐怖的不是bug被改变了，而是不管你怎么改，那个bug都没有变过，你知道这意味着什么吗？

2，我有时候觉得，我是心里变态的，因为我特别希望系统整出个大bug，最好是那种，无从下手的bug。 这想法不好，我得改！

3，我觉得，改bug是一件很有成就感和幸福感的事儿，我以前是苦逼的挖坑，现在是幸福的挖坑，然后幸福的填坑。 我改bug可开心了，果然天生的劳碌命，一辈子的码农啊。。。。。。