[ https://issues.apache.org/jira/browse/IGNITE-6070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ilya Kasnacheev reassigned IGNITE-6070: --------------------------------------- Assignee: Ilya Kasnacheev > 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 > Assignee: Ilya Kasnacheev > Priority: Minor > Labels: easyfix, newbie > Attachments: IGNITE-6070.patch, webtest.zip > > > 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)