Spring Security与BlazeDS集成的FlexSession Invalid问题

最新推荐文章于 2021-02-06 19:02:00 发布

songzi0206

最新推荐文章于 2021-02-06 19:02:00 发布

阅读量221

点赞数 1

分类专栏： Spring 文章标签： Spring Security Blazeds Invalid session

本文链接：https://blog.csdn.net/songzi0206/article/details/84213275

版权

Spring 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

先说现象：当用户登录以后，如果点击浏览器的后退按钮回到登录页面，这个时候用浏览器的前进按钮是可以再回到主页面的，但如果再想通过输入用户名/密码登录的时候，就会发现登录不了，系统会一直跳转到登录页面。查看后台的话会发现这个是因FlexSession invalid Exception 引起的。
仔细想想觉得系统不应该会有这种bug啊，但是不管你觉得会不会，问题出现了，而且还非常容易重现。先查了下blazeds的jira，还真发现有人提过这个bug（ http://bugs.adobe.com/jira/browse/BLZ-350 ），但是看这个issue的comments说考虑会在版本4中改，又说在spring security中改更容易，还给了一个spring security jira的连接。

果然，spring security jira中也有人提过这个bug（https://jira.springsource.org/browse/SEC-1109 ），看了下解决方案是通过实现自己的SessionAuthenticationStrategy在销毁/复制旧session的时候特殊处理“__flexSession”属性。
也就是说双方都没改，只是提供了修复建议，默认配置还是会出现这个bug，有点意思，呵呵！那就查看下source code，自己探其究竟吧:

先说blazeds，他提供了一个叫做HttpFlexSession的session监听器，他会去监听HttpSession，从而维护了一套与HttpSession对应的属性，而它自己也会作为HttpSession的__flexSession属性存在。

当HttpSession销毁的时候，HttpFlexSession的sessionDestory方法触发，该方法会清理HttpFlexSession所占的资源，从而使得其自身invalidate()，即当前的这个HttpFlexSession已经不可用了，但是他并不会将自己从HttpSession中清理掉，也没有将自己设置为null。参考代码：

public void sessionDestroyed(HttpSessionEvent event)
    {
        HttpSession session = event.getSession();
        Map httpSessionToFlexSessionMap = getHttpSessionToFlexSessionMap(session);
        HttpFlexSession flexSession = (HttpFlexSession)httpSessionToFlexSessionMap.remove(session.getId());
        if (flexSession != null)
        {
            // invalidate the flex session
            flexSession.superInvalidate();

            // Send notifications to attribute listeners if needed.
            // This may send extra notifications if attributeRemoved is called first by the server,
            // but Java servlet 2.4 says session destroy is first, then attributes.
            // Guard against pre-2.4 containers that dispatch events in an incorrect order, 
            // meaning skip attribute processing here if the underlying session state is no longer valid.
            try
            {
                for (Enumeration e = session.getAttributeNames(); e.hasMoreElements(); )
                {
                    String name = (String) e.nextElement();
                    if (name.equals(SESSION_ATTRIBUTE))
                        continue;
                    Object value = session.getAttribute(name);
                    if (value != null)
                    {
                        flexSession.notifyAttributeUnbound(name, value);
                        flexSession.notifyAttributeRemoved(name, value);
                    }
                }
            }
            catch (IllegalStateException ignore)
            {
                // NOWARN
                // Old servlet container that dispatches events out of order.
            }
        }
    }

这个没有错，因为从blazeds的角度看，上面的一系列动作是在HttpSession销毁时候触发的，既然HttpSession都销毁了，也就没有必要再去一个已销毁的对象里remove掉属性(贸然的remove还可能有nullpointorexception)！
再来看看Spring Security，当用户进行Authentication的时候（默认是提交j_spring_security_check请求）会经过SessionManagementFilter，若authentication已经存在(即已经认证过)，该filter默认会调用SessionFixationProtectionStrategy的onAuthentication方法，该方法会复制已经存在的那个HttpSession的所有属性，然后就销毁之，接着会创建一个新的HttpSession并把刚刚复制的所有属性set到这个新session中。参考代码：

public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
            throws IOException, ServletException {
        HttpServletRequest request = (HttpServletRequest) req;
        HttpServletResponse response = (HttpServletResponse) res;

        if (request.getAttribute(FILTER_APPLIED) != null) {
            chain.doFilter(request, response);
            return;
        }

        request.setAttribute(FILTER_APPLIED, Boolean.TRUE);

        if (!securityContextRepository.containsContext(request)) {
            Authentication authentication = SecurityContextHolder.getContext().getAuthentication();

            if (authentication != null && !authenticationTrustResolver.isAnonymous(authentication)) {
             // The user has been authenticated during the current request, so call the session strategy
                try {
                    sessionStrategy.onAuthentication(authentication, request, response);
                } catch (SessionAuthenticationException e) {
                    // The session strategy can reject the authentication
                    logger.debug("SessionAuthenticationStrategy rejected the authentication object", e);
                    SecurityContextHolder.clearContext();
                    failureHandler.onAuthenticationFailure(request, response, e);

                    return;
                }
                // Eagerly save the security context to make it available for any possible re-entrant
                // requests which may occur before the current request completes. SEC-1396.
                securityContextRepository.saveContext(SecurityContextHolder.getContext(), request, response);
            } else {
             // No security context or authentication present. Check for a session timeout
                if (request.getRequestedSessionId() != null && !request.isRequestedSessionIdValid()) {
                    logger.debug("Requested session ID" + request.getRequestedSessionId() + " is invalid.");

                    if (invalidSessionUrl != null) {
                        logger.debug("Starting new session (if required) and redirecting to '" + invalidSessionUrl + "'");
                        request.getSession();
                        redirectStrategy.sendRedirect(request, response, invalidSessionUrl);

                        return;
                    }
                }
            }
        }

        chain.doFilter(request, response);
    }

public void onAuthentication(Authentication authentication, HttpServletRequest request, HttpServletResponse response) {
        boolean hadSessionAlready = request.getSession(false) != null;

        if (!hadSessionAlready && !alwaysCreateSession) {
            // Session fixation isn't a problem if there's no session

            return;
        }

        // Create new session if necessary
        HttpSession session = request.getSession();

        if (hadSessionAlready && request.isRequestedSessionIdValid()) {
            // We need to migrate to a new session
            String originalSessionId = session.getId();

            if (logger.isDebugEnabled()) {
                logger.debug("Invalidating session with Id '" + originalSessionId +"' " + (migrateSessionAttributes ?
                        "and" : "without") +  " migrating attributes.");
            }

            HashMap<String, Object> attributesToMigrate = createMigratedAttributeMap(session);

            session.invalidate();
            session = request.getSession(true); // we now have a new session

            if (logger.isDebugEnabled()) {
                logger.debug("Started new session: " + session.getId());
            }

            if (originalSessionId.equals(session.getId())) {
                logger.warn("Your servlet container did not change the session ID when a new session was created. You will" +
                        " not be adequately protected against session-fixation attacks");
            }

            // Copy attributes to new session
            if (attributesToMigrate != null) {
                for (Map.Entry<String, Object> entry : attributesToMigrate.entrySet()) {
                    session.setAttribute(entry.getKey(), entry.getValue());
                }
            }
        }
    }

从Spring Security角度看，这个也没有错啊！已经认证过的用户再次认证，我的策略就是复制一个新的session。这也难怪双方都没有去改框架的代码。

正如JIRA上的建议，也从源码可看到在SessionManagementFilter中，SessionAuthenticationStrategy是可以自己配置的：

public void setSessionAuthenticationStrategy(SessionAuthenticationStrategy sessionStrategy) {
        Assert.notNull(sessionStrategy, "authenticatedSessionStratedy must not be null");
        this.sessionStrategy = sessionStrategy;
    }

所以，解决的一个方法便很简单了，不要使用SessionManagementFilter中默认的SessionFixationProtectionStrategy，而是实现自己的SessionAuthenticationStrategy并配置给SessionManagementFilter中即可。至于自己实现SessionAuthenticationStrategy，在将属性复制到新session的时候，判断下如果是HttpFlexSession就不要复制进去了，呵呵！

上面的这个方法改动是最少的，就是写个新类实现SessionAuthenticationStrategy接口配置下。但是如果不想对Spring Security扩展，我觉得也可以用扩展blazeds的思路来实现。尝试了两种，第一种通过实现一个FlexSessionListener去监听HttpFlexSession，当触发sessionDestory的时候将HttpFlexSession.httpSession里的HttpFlexSession属性移除掉，但是这种方法不对的 ，因为这个方法被触发之前，httpSession里的所有属性已经被复制了，再移除已经无用。第二种，重写MessageBrokerServlet的service方法，因为异常的源头来自该servlet用了一个invalid的HttpFlexSession去获取Principal，所以只要再service方法之前先判断下当前的HttpFlexSession是否已经无效，无效的话我们就从当前的HttpSession中移除这个无效的HttpFlexSession即可。这样，就能保证MessageBrokerServlet中所用的HttpFlexSession一定是有效的。

@Override
	public void service(HttpServletRequest req, HttpServletResponse res) {
		HttpSession httpSession = req.getSession(true);
		HttpFlexSession flexSession = (HttpFlexSession)httpSession.getAttribute(XXWebServlet.SESSION_ATTRIBUTE);
		if( flexSession != null && !flexSession.isValid()){
			httpSession.removeAttribute(XXWebServlet.SESSION_ATTRIBUTE);
		}
		super.service(req, res);
	}