springboot的shiro配置之过滤器

  • Post author:
  • Post category:其他


springboot整合shiro的文章到处都是。包括springboot的官网都有相应的例子。但是这块有个注意点,需要那些从springmvc迁到springboot的朋友注意下。这个问题困扰我了两三天,今天分享出来让后来人少踩坑。

spring整合shiro的时候我们会配置一个shiro.xml文件,将shiro的配置信息全部配置进去然后在web.xml里面配置一个过滤器代理就足够了。

 <filter>
        <filter-name>shiroFilter</filter-name>
        <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
        <async-supported>true</async-supported>
        <init-param>
            <param-name>targetFilterLifecycle</param-name>
            <param-value>true</param-value>
        </init-param>
    </filter>

但是到了springboot情况有所不同。之前我按照之前的方法原原本本的将shiro配置都写到了java文件中,并没有发现什么问题。可是真的使用的时候我发现了一个问题–过滤器链在无限次的自循环执行!

过滤器链后面连着servlet是一个完整的uri请求执行的路径。可是过滤器链自己无限次的循环执行,servlet根本执行不找,那么view也就不可能返回给前台页面,导致页面总是报连接异常。

找这个问题我也是走了很多的弯路。首先查找配置文件是不是配置错误了,找了几遍和网上写的都是一致的。然后一直在跟jetty的ServletHandler这个类。

 @Override
        public void doFilter(ServletRequest request, ServletResponse response)
            throws IOException, ServletException
        {
            final Request baseRequest=Request.getBaseRequest(request);

            // pass to next filter
            if (_filterHolder!=null)
            {
                if (LOG.isDebugEnabled())
                    LOG.debug("call filter {}", _filterHolder);
                Filter filter= _filterHolder.getFilter();
                
                //if the request already does not support async, then the setting for the filter
                //is irrelevant. However if the request supports async but this filter does not
                //temporarily turn it off for the execution of the filter
                if (baseRequest.isAsyncSupported() && !_filterHolder.isAsyncSupported())
                { 
                    try
                    {
                        baseRequest.setAsyncSupported(false,_filterHolder.toString());
                        filter.doFilter(request, response, _next);
                    }
                    finally
                    {
                        baseRequest.setAsyncSupported(true,null);
                    }
                }
                else
                    filter.doFilter(request, response, _next);

                return;
            }

            // Call servlet
            HttpServletRequest srequest = (HttpServletRequest)request;
            if (_servletHolder == null)
                notFound(baseRequest, srequest, (HttpServletResponse)response);
            else
            {
                if (LOG.isDebugEnabled())
                    LOG.debug("call servlet " + _servletHolder);
                _servletHolder.handle(baseRequest,request, response);
            }
        }

我很疑惑为什么这里面的_servletHolder为空!!(对底层不了解,为空也不知为啥。)

后来我想过滤器链无限循环就关注过滤器链。现在我配置了a,b,c,d四个过滤器,这四个过滤器应该被包装在spring的DelegatingFilterProxy过滤器代理e中,而DelegatingFilterProxy过滤器代理会被包装成FilterRegistrationBean类型的f。也就是说过滤器链应该是形如这样的

e(a,b,c,d包含其中)->f-Dispacher

而我发现项目中的过滤器是酱紫的:a->b->c->d->e->f->Dispacher

其中c过滤器(LogoutFilter)过滤了所有请求,使用了shiro的页面跳转规则

WebUtils类
 public static void issueRedirect(ServletRequest request, ServletResponse response, String url, Map queryParams, boolean contextRelative, boolean http10Compatible) throws IOException {
        RedirectView view = new RedirectView(url, contextRelative, http10Compatible);
        view.renderMergedOutputModel(queryParams, toHttp(request), toHttp(response));
    }

我们配置的spring跳转规则自然会无法正常跳转。这是无语啊~~

后来想想,spring大费周章的将这些过滤器代理了,到了springboot又来一个FilterRegistrationBean包装spring的代理过滤器。而现在这些过滤器裸露在外,肯定是配置的问题。

于是按照以下配置修改了xml的配置

  <bean id="shiroFilter" class="org.apache.shiro.spring.web.ShiroFilterFactoryBean">
        <property name="securityManager" ref="securityManager"/>
        <property name="loginUrl" value="${shiro.login.url}"/>
        <property name="unauthorizedUrl" value="${shiro.unauthorizedUrl}"/>
        <property name="filters">
            <util:map>
                <entry key="authc">
                    <bean id="formAuthenticationFilter"
                          class="*.*.a">
                      
                    </bean>
                </entry>
                <entry key="logout">
                    <bean id="logoutFilter" class="*.*.b">
                </entry>
                <entry key="sysUser">
                    <bean id="sysUserFilter" class="*.*.c">
                       
                    </bean>
                </entry>
                <entry key="onlineSession">
                    <bean id="onlineSessionFilter"
                          class="*.*.d">
                        
                    </bean>
                </entry>
                <entry key="syncOnlineSession">
                    <bean id="syncOnlineSessionFilter"
                          class="*.*.e">
                        <property name="onlineSessionDAO" />
                    </bean>
                </entry>
                <entry key="myfilter">
                    <bean id="myFilter" class="*.*.f"/>
                </entry>
            </util:map>
        </property>
        <property name="filterChainDefinitions">
            <value>
                /static/** = anon
                /js/** =anon
                /css/** =anon
                /favicon.ico =anon
                /images/** = anon
                /logout = logout
                /user/login=authc
                /** =sysUser,onlineSession,syncOnlineSession,perms,roles
            </value>
        </property>
    </bean>

这样的配置后,过滤器链恢复了正常,这些自定义的过滤器包装在了代理过滤器中。

这个问题之所以是个问题,还在于对以下几个问题没搞清楚:

1、FilterRegistrationBean类的实现机制

2、shiro过滤器链的实现机制

下面我就从这两个方面说说我最近看到的。

#FilterRegistrationBean类的实现机制

说到这个类我们先来说说在没有整合springboot的时候我们在web.xml里面配置的类DelegatingFilterProxy。

在web.xml里面我们只要将真正的shiroFilter的id和这个类的过滤器名称配置一致就能够实现代理。

这个原理很简单,DelegatingFilterProxy这个类会根据这个id名称在spring容器中找到这个类。

protected Filter initDelegate(WebApplicationContext wac) throws ServletException {
		Filter delegate = wac.getBean(getTargetBeanName(), Filter.class);
		if (isTargetFilterLifecycle()) {
			delegate.init(getFilterConfig());
		}
		return delegate;
	}

然后调用shiroFilter的init方法,将我们配置的一堆过滤器和一堆映射转换成相应的字段信息

    public void init() throws Exception {
        WebEnvironment env = WebUtils.getRequiredWebEnvironment(getServletContext());

        setSecurityManager(env.getWebSecurityManager());

        FilterChainResolver resolver = env.getFilterChainResolver();
        if (resolver != null) {
            setFilterChainResolver(resolver);
        }
    }
}

到了springboot里面又有加了这个类FilterRegistrationBean,将代理过滤器又包装了起来。主要是因为springboot在启动spring容器的时候会调用以下方法将过滤器加载到servlet上下文。

	FilterRegistration.Dynamic added = servletContext.addFilter(name, filter);

也就是说之前我们的delegate配置到了web.xml直接能够放到servlet上下文。到了springboot它不默认去读web.xml。那么到springboot中delegateFilter是通过这个FilterRegistrationBean类放置到servlet上下文的。

下次再加载什么类,是不是可以想想这个类。

2、shiro过滤器链的实现机制

shiro的过滤器链算是比较重要的部分。今天有必要大体了解下。

shiro中包括自定义过滤器和shiro自己的过滤器又很多很多。他们组织在一起的机制是什么呢?

shiro的filter是一个工厂类ShiroFilterFactoryBean生产出来的,生产出来的过滤器类型是SpringShiroFilter。

这个类型里面包含了两个参数:一个是安全管理器,一个是过滤器链解析器

    PathMatchingFilterChainResolver chainResolver = new PathMatchingFilterChainResolver();
        chainResolver.setFilterChainManager(manager);

        //Now create a concrete ShiroFilter instance and apply the acquired SecurityManager and built
        //FilterChainResolver.  It doesn't matter that the instance is an anonymous inner class
        //here - we're just using it because it is a concrete AbstractShiroFilter instance that accepts
        //injection of the SecurityManager and FilterChainResolver:
        return new SpringShiroFilter((WebSecurityManager) securityManager, chainResolver);

输入图片说明

从图中可以看出SpringShiroFilter实现了servlet3.0的Filter接口,并且继承了OncePerRequestFilter类。所以它既是一个普通的类,有是包含了shiro特性的代理类。 无论是shiroFilter还是代理过滤器SpringShiroFilter都是继承自AbstractShiroFilter,过滤器执行方法如下:

   protected void executeChain(ServletRequest request, ServletResponse response, FilterChain origChain)
            throws IOException, ServletException {
        FilterChain chain = getExecutionChain(request, response, origChain);
        chain.doFilter(request, response);
    }

chain的类型是代理过滤器链ProxiedFilterChain,这样shiro的内部过滤器链执行过程和其他的过滤器链执行过程很类似。

  public void doFilter(ServletRequest request, ServletResponse response) throws IOException, ServletException {
        if (this.filters == null || this.filters.size() == this.index) {
            //we've reached the end of the wrapped chain, so invoke the original one:
            if (log.isTraceEnabled()) {
                log.trace("Invoking original filter chain.");
            }
            this.orig.doFilter(request, response);
        } else {
            if (log.isTraceEnabled()) {
                log.trace("Invoking wrapped filter at index [" + this.index + "]");
            }
            this.filters.get(this.index++).doFilter(request, response, this);
        }
    }

有了代理类SpringShiroFilter,它代理的那些过滤器都有一个特点:继承自AdviceFilter 该类有以下部分组成: ##过滤器链继续执行前

    protected boolean preHandle(ServletRequest request, ServletResponse response) throws Exception {
        return true;
    }

继承类可以覆盖该方法在过滤器链执行前,做一些自己想要的操作。 ##过滤链执行

rotected void executeChain(ServletRequest request, ServletResponse response, FilterChain chain) throws Exception {
        chain.doFilter(request, response);
    }

这个是过滤器链执行过程。 ##过滤器链执行完以后(正常)

 protected void postHandle(ServletRequest request, ServletResponse response) throws Exception {
    }

过滤器链执行之后执行该方法,继承类可以覆盖该方法在过滤器链执行后,做一些想要的操作。 ##过滤链执行完成

    public void afterCompletion(ServletRequest request, ServletResponse response, Exception exception) throws Exception {
    }

过滤器链在执行的过程中可能抛出异常,这个时候过滤器之后的操作都将无法执行。但是afterCompletion方法无论过滤器链在正常完成或是异常完成的情况下都会被执行。该方法特别适合完成一些后期的清除工作。(类似finnally原理)。

有了执行功能的过滤器,有了这些过滤器的代理过滤器。那么还有一个问题就清楚过滤器了:过滤器执行。

#过滤器执行 代理过滤器实现了接口AbstractShiroFilter。它内部的过滤器是通过方法doFilterInternal实现的。

 protected void doFilterInternal(ServletRequest servletRequest, ServletResponse servletResponse, final FilterChain chain)
            throws ServletException, IOException {

        Throwable t = null;

        try {
            final ServletRequest request = prepareServletRequest(servletRequest, servletResponse, chain);
            final ServletResponse response = prepareServletResponse(request, servletResponse, chain);

            final Subject subject = createSubject(request, response);

            //noinspection unchecked
            subject.execute(new Callable() {
                public Object call() throws Exception {
                    updateSessionLastAccessTime(request, response);
                    executeChain(request, response, chain);
                    return null;
                }
            });
        } catch (ExecutionException ex) {
            t = ex.getCause();
        } catch (Throwable throwable) {
            t = throwable;
        }

1、包装shiro的request类。

2、包装shiro的response类。

3、创建subject实例

4、调用subject实例的execute方法执行callable类的call()方法。

5、call()方法做了两件事情:更新session最新访问时间,执行shiro内部能够处理本次request请求的过滤器链(通过过滤器链解析器过滤出来的),并执行。

执行过程很巧妙,将任务包装成callable并将其放入subject的execute方法中。

 public <V> V execute(Callable<V> callable) throws ExecutionException {
        Callable<V> associated = associateWith(callable);
        try {
            return associated.call();
        } catch (Throwable t) {
            throw new ExecutionException(t);
        }
    }

该方法将callable继续包装成SubjectCallable实例。

 public <V> Callable<V> associateWith(Callable<V> callable) {
        return new SubjectCallable<V>(this, callable);
    }

最后调用的是SubjectCallable的call方法。

   public V call() throws Exception {
        try {
            threadState.bind();
            return doCall(this.callable);
        } finally {
            threadState.restore();
        }
    }

call方法做了两件事情:

1、获取该线程的subject信息,并且将securityManager绑定到该线程中。

2、调用doCall方法执行过滤器链。

过滤器链是shiro的核心,但是不恰当的配置会导致过滤器链死循环执行。理解shiro的过滤器链实现原理,能够在我们排解相关错误做一个基础。


欢迎关注我的微信号:hyssop的后花园


转载于:https://my.oschina.net/zjItLife/blog/791660