ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilya Kasnacheev (JIRA)" <j...@apache.org>
Subject [jira] [Created] (IGNITE-6070) Infinite redirects at Spring Security Web Session Clustering with Tomcat
Date Tue, 15 Aug 2017 16:09:00 GMT
Ilya Kasnacheev created IGNITE-6070:

             Summary: Infinite redirects at Spring Security Web Session Clustering with Tomcat
                 Key: IGNITE-6070
                 URL: https://issues.apache.org/jira/browse/IGNITE-6070
             Project: Ignite
          Issue Type: Bug
          Components: websession
    Affects Versions: 2.1
         Environment: Spring Security, Apache Tomcat
            Reporter: Ilya Kasnacheev
            Priority: Minor

See https://stackoverflow.com/questions/45648884/apache-ignite-spring-secutiry-error description.

When Session comes from Ignite but its Authentication is anonymous, Spring Security does the
following check:

                } else if (request.getRequestedSessionId() != null && !request.isRequestedSessionIdValid())
                        this.logger.debug("Requested session ID " + request.getRequestedSessionId()
+ " is invalid.");
                        this.invalidSessionStrategy.onInvalidSessionDetected(request, response);

The problem is, in Ignite we never override isRequestedSessionIdValid() in our request wrappers,
so it falls back to Tomcat's own (session) Manager, which will then find that it has never
seen this Session and it is therefore invalid. Thus failover is triggered, and if there's
"invalid-session-url" clause in Spring Security config, redirect will be issued, possibly

I've attaching a sample Maven WAR project. It should be deployed to two different Tomcat instances
operating on two different ports of same machine, e.g. 8080 and 8180, and then http://localhost:PORT/webtest-1.0-SNAPSHOT/index.jsp
should be opened in the same Web Browser one after another for two ports. The second one should
cause infinite 302 Redirect to same URL.

There's also a minor bug in the same code: see session.jsp in the example. It will needlessly
throw NPE in WebSessionFilter:1001 and confuse web server. Should output "OK" when fixed.


By the way, letting the web server to get hold on Sessions that it creates for us causes additional
problems: it's going to store these sessions in parallel with Ignite, consuming memory in
the process that first saw a given session. We should probably have (possibly a third party)
an Ignite-using Manager implementation for Tomcat specifically. It will be much simpler than
filter-based approach while performing better.

Or maybe we should create our own Sessions that we never allow the web server to see.

This message was sent by Atlassian JIRA

View raw message