Am 30.01.2015 um 03:06 schrieb Christopher Schultz:
On 7/23/14 5:14 PM, Christopher Schultz wrote:
Rainer,
On 7/23/14, 4:10 PM, Rainer Jung wrote:
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.
That's a good thought, and simplifies things. The request
parameter could then just be a boolean flag and not actually
identify the node that produced the redirect: any node considering
redirecting simply would not redirect if that flag had been set.
So, I've implemented all of the above and just given it a real
test-drive in production. It seems to work well on the first shot.
Good!
I'll be testing it a bit more as time does on, actually. I also
converted it to a Valve that I will propose to include in Tomcat once
I get some real mileage on it.
Was a Valve more useful than a filter? Did you need to access Tomcat
internals?
I also discovered that I'd like to have a new feature: the ability for
a whitelisted client to ignore the re-balance rules and continue to
contact the server. So, if you have a cluster member called, say,
"foo" and you want to force your way into "foo", you can make a
request to any page with a jsessionid parameter:
http://host/some_page;jsessionid=1234.foo
mod_jk will send you to the "foo" node, even though it is in the
DISABLED state.
Normally, my Filter/Valve would see that you have no valid session
("1234.foo" is not valid) and perform a redirect without the
"jsessionid" path parameter added, thus re-balancing you to another node.
Instead, I've added the ability to configure an "ignore" cookie and
cookie value (like "ignore=SECRETCODE"). If the client presents this
cookie to the Filter/Valve, then it's business as usual.
This allows a trusted user to log into the DISABLED node through the
load-balancer to take a look around, make sure that things are working
properly, etc. before re-enabling the node in the cluster. I'll give
this a shot in the next few days, clean it all up, and publish it (soon?).
That sounds useful.
Thanks!
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
