-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Rainer,
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. 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. 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?). - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUyucgAAoJEBzwKT+lPKRYi8wQAIi+G/hb0IxXem+yp56n8Lw1 M2TfALSw6JeSmTTrqj6tRDW91b26zj7+3pSZQp0HBkZNiWEZfZNmurLEHe5baWCV KmKY//zSX8LPOCrTR+hRQ95VAmRIw918OYdgFlRYEQ11Tx45UOr5ivNsAJRfARPw KdBf3mo3mOKlxjxPEphlZdL6CJojjz0psToc412t3hPf3u2ttxKo0wSn8hDi47O3 bbdpwoA6vpCW7vLRPI22kZoJe4nbsFz0IS26smzVXjarbyrzt/YNHMPhuFSrXSIn kQhvZeF/61/ZDbOS/54VmfoVugRlcoUiw1nm4Fpvv1xWeezZw7DteCJ/SuqvjbVo 1Y+6wYomMj91Viw8HqNBxh1nXcLUP8tYKqCT1H7MM5sjgMQFonoIdtKMSWbLO8qQ zDi4qvJudWyGazxWsjTcy9iRyrVqjbkZ0SiVt6trKHyu7NPWBK2CcO3BoznJXs1M fFsmBTvAFMZLicqenlniPazMQhGzrdfl2QaixPI0moUhnscYoZfUXFhrZaQ0z83v GKL/MiQDeImZLsi1hup2C8/ML4lkPIj3TS0fP6BxMQZ1Bk6NB6EJ0yJjLq0aH/Kd 6dyax4kfRbG88wxtlzmAF1ryceoq2/hU7wHryhDBOuzLTmWCb9jfEw3pHTn6UOsZ GKyVmm7oT9//JH8KGXQB =n5w9 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
