[jira] [Created] (IGNITE-6070) Infinite redirects at Spring Security Web Session Clustering with Tomcat

["Ilya Kasnacheev (JIRA)" <ji...@apache.org>]

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:

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

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 circular.

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.

Discussion:

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
(v6.4.14#64029)