[
https://issues.apache.org/jira/browse/IGNITE-6070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-6070:
------------------------------------
Attachment: webtest.zip
Maven project to reproduce the issue
> 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
> 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)
