Uploaded image for project: 'Ignite'
  1. Ignite
  2. IGNITE-6070

Infinite redirects at Spring Security Web Session Clustering with Tomcat

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 2.1
    • Fix Version/s: 2.3
    • Component/s: websession
    • Labels:
    • Environment:

      Spring Security, Apache Tomcat

    • Flags:
      Patch

      Description

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

        Attachments

        1. IGNITE-6070.patch
          1.0 kB
          Ilya Kasnacheev
        2. webtest.zip
          7 kB
          Ilya Kasnacheev

          Issue Links

            Activity

              People

              • Assignee:
                ilyak Ilya Kasnacheev
                Reporter:
                ilyak Ilya Kasnacheev
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: