Am 23.07.2014 um 21:03 schrieb Christopher Schultz:
On 7/23/14, 1:49 PM, Rainer Jung wrote:
The other case, a request with an invalid session ID accessing a
tomcat instance with activation disabled can IMHO be handled by a
filter that
- checks whether the request has a valid session using
getSession(false), if it has one, let the request proceed
- checks activation state, if "active", let the request proceed
- checks the request method, if not GET, let the request proceed
- otherwise:
- set the session cookie, e.g. JSESSIONID the an empty value -
issue an external redirect to the same request URL - optional
redirect loop detection: add a query string param or cookie that
gets the local jvmRoute appended during each redirect. Before
doing the redirect, check that the local jvmRoute is not already
part of that token (we have already been here before)
This would not really interfere with your saved requests: they
would get a redirect which the browser follwos automatically and
after that you will observe the normal behavior.
This is exactly what I have implemented -- as a Filter since we can
insert it before SecurityFilter intercepts the requests -- and my
tests suggest that it will work correctly.
I added code to strip-out any ;jsessionid path parameter from the URL
ACK
if it exists, but haven't done any of the redirect loop detection
(yet). I think the loop detection is going to have to keep a running
list of visited nodes which, in large clusters, could grow very large
especially if the node names are long. I'll post my code when it's a
little more featureful.
As long as nothing goes wrong, the first redirect - having no more
session info - should not end up in getting redirected as well, because
it should only be send to an active node by mod_jk. So you can even stop
redirecting if you detect, that it already happened once. For a large
cluster that might be better.
Multiple might happen (didn't check the code), if all active members are
in error state. Even then one would not like to produce many of those
redirects for one request, so again, only allowing one redirect might be
the right solution.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
