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)
