First create a Valve and in the invoke(...) method and do whatever you do to figure out how you are tracking sessions. I personally checked to see if a query parameter is set. I also tried checking if the requested RemoteUser on authenticated connections but that doesn't work because Tomcat does that in org.apache.catalina.authenticator.AuthenticatorBase which is after any Valves you can setup via server.xml.
Then once you've figured out what token your tracking sessions by, put that in a ThreadLocal that can be later accessed by a custom Manager.
Now subclass StandardManager overriding createSession() and generateSessionId().
My generateSessionId() method first checks the ThreadLocal mentioned above for a token. If it's null, then just pass things off to super.generateSessionId() else return that token.
My createSession() method checks the same ThreadLocal for a token, if it's null, just pass things off to super.createSession() else try to findSession(token). If findSession(token) returns null, pass things off to super.createSession() else return the found session. You have to findSession(token) when you are using your custom token else the super.createSession() will get stuck in an infinite loop trying to generate a unique session id which won't happen because of your custom generateSessionId method always returning the same value.
Thinking more on it, you could probably stuff the request.getRequest() from your Valve in the ThreadLocal and then later getRemoteUser() in your custom Manager. I haven't tried that yet, but I do like the idea of tracking sessions based on authenticated user's as opposed to a query parameter.
Hope someone finds this useful.
Sandy McArthur
PGP.sig
Description: This is a digitally signed message part
