解决errorpage里面取不到Authentication的问题

 项目中遇到一个很奇怪的问题，在错误页面404里面取不到当前登录用户，即 SecurityContextHolder.getContext().getAuthentication()取不到当前的登陆用户信息。这个问题花了我很长时间最终搞定了，下面讲一下解决问题的过程。
          首先来看一下项目的异常处理方式，在web.xml里面配置了错误页：
Xml代码:
1.<error-page>
2.        <error-code>404</error-code>
3.        <location>/WEB-INF/pages/errors/404.jsp</location>
4.    </error-page>
           当访问一个不存在的url时，spring的前端控制器的逻辑如下：
        其实就是会调用noHandlerFound函数，然后直接退出DispatcherServlet。
        我们再来一下noHandlerFound的逻辑：

         在这个里面实际上是返回一个404的错误，真正的错误页面处理的转向是由tomcat容器来完成的。通过调试发现在这个地方SecurityContextHolder.getContext().getAuthentication()还有值，但是访问404页面的tag里面就取不到了，后来通过监控网络发现，访问errorpage是由容器重新发起的一个请求，这个请求里面拿不到Authentication可能是没有走springsecurity的前端拦截器 springSecurityFilterChain。
         我们来看一下springSecurityFilterChain filter的配置：
Xml代码:

1.<filter>
2.        <filter-name>springSecurityFilterChain</filter-name>
3.        <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
4.    </filter>
5.    <filter-mapping>
6.        <filter-name>springSecurityFilterChain</filter-name>
7.        <url-pattern>/*</url-pattern>
8.    </filter-mapping>

         突然想到极有可能是这个filter没有转发，后来看了下filter-mapping的配置，还真是这样。filter-mapping里面接受dispatcher参数。
         我们就来看一下这个参数的含义。
 
          2.4版本的servlet规范在部属描述符中新增加了一个<dispatcher>元素，这个元素有四个可能的值：即REQUEST,FORWARD,INCLUDE和ERROR，可以在一个<filter-mapping>元素中加入任意数目的<dispatcher>，使得filter将会作用于直接从客户端过来的request，通过forward过来的request，通过include过来的request和通过<error-page>过来的request。如果没有指定任何< dispatcher >元素，默认值是REQUEST。
            可以通过下面几个例子来辅助理解。
Xml代码:

1. <filter-mapping> 
2. <filter-name>Logging Filter</filter-name> 
3. <url-pattern>/products/*</url-pattern> 
4. </filter-mapping>

           这种情况下，过滤器将会作用于直接从客户端发过来的以/products/…开始的请求。因为这里没有制定任何的< dispatcher >元素，默认值是REQUEST。
Xml代码:

1. <filter-mapping> 
2. <filter-name>Logging Filter</filter-name> 
3. <servlet-name>ProductServlet</servlet-name> 
4. <dispatcher>INCLUDE</dispatcher> 
5. </filter-mapping> 

        这种情况下，如果请求是通过request dispatcher的include方法传递过来的对ProductServlet的请求，则要经过这个过滤器的过滤。其它的诸如从客户端直接过来的对ProductServlet的请求等都不需要经过这个过滤器。
        指定filter的匹配方式有两种方法：直接指定url-pattern和指定servlet，后者相当于把指定的servlet对应的url-pattern作为filter的匹配模式
filter的路径匹配和servlet是一样的，都遵循servlet规范中《SRV.11.2 Specification of Mappings》一节的说明
 
Xml代码:

1. <filter-mapping> 
2. <filter-name>Logging Filter</filter-name> 
3. <url-pattern>/products/*</url-pattern> 
4. <dispatcher>FORWARD</dispatcher> 
5. <dispatcher>REQUEST</dispatcher> 
6. </filter-mapping> 

         看了这个，我修改了下springSecurityFilterChain的filter-mapping的配置，就     好了。
          修改后的配置如下：
Xml代码:
 

1. <filter>
2.         <filter-name>springSecurityFilterChain</filter-name>
3.         <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
4.     </filter>
5.     <filter-mapping>
6.         <filter-name>springSecurityFilterChain</filter-name>
7.         <url-pattern>/*</url-pattern>
8.         <dispatcher>REQUEST</dispatcher>
9.         <dispatcher>ERROR</dispatcher>
10.     </filter-mapping>

         意思就是直接从客户端过来的request和通过<error-page>过来的request 都要走这个filter，配置完后就果断好了。
         好了，就写到这里了，希望对大家有所帮助。关于springSecurityFilterChain这个我会另写一篇博客进行详细讲解。
本人原创，发现一些网站无道德的抓取，请自觉删去内容，转载请注明出处:http://www.software8.co/wzjs/java/2797.html

本文链接