-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Peter,
Peter Stavrinides wrote:
| Tom this is 100% correct "there is no way to even instantiate a session
| object from a self-supplied session-id let alone replace the current
| session object in the HttpRequest."
That depends on your definition of "no way" ;)
| I apologise Christopher for second guessing, but I just don't see what
| rewriting Tomcats session management brings... you did say nevertheless
| that you don't recommend it, for good reason, this is tried and tested
| code that is central to the servers operation, I feel this task is
| 'unthinkable' and will only introduce a host of problems and complexity.
I said that I didn't recommend re-writing session management as a filter
(because of the overwhelming complexity involved in satisfying all the
requirements). I actually /do/ recommend hacking the Tomcat code. I
think it's the only reasonable way to do this.
Re-writing Tomcat's session management allows Tom to override the source
of the session ids (custom HTTP header instead of URL parameter or
cookie) as well as the way they are sent back to the client (again,
custom HTTP header instead of cookie). This seems like the least amount
of work that could get the job done.
Since the problem is in two parts (get and set) and CoyoteAdapter seems
to only handle the first part (getting the session id from the client)
while org.apache.catalina.connector.Request seems to handle setting the
Cookie on the response, the solution might not be nice and symmetrical.
Actually, now that I get into it, it looks like a single Valve might be
able to do this. The basic method in a Valve is:
public void invoke(Request request, Response response)
where both of the parameters are in the org.apache.catalina.connector
package. The Request class has a "setRequestedSessionId" method that you
could use to override the default source. Setting the outgoing header
might be a little trickier because Request.doGetSession is the method
that actually creates and adds the cookie to the response.
Maybe something like this would work:
public class CustomHeaderSessionIdValve
~ extends org.apache.catalina.valves.ValveBase
{
~ public static final String CUSTOM_HEADER_NAME = "X-My-SessionId";
~ public void invoke(Request request, Response response)
~ {
~ // You might consider ignoring your own custom header
~ // if the session id already came through a cookie
~ // or URL parameter. I'm not sure if you trust them,
~ // but you might want to use your custom header only
~ // for fall-back.
~ String customSessionId = request.getHeader(CUSTOM_HEADER_NAME);
~ if(null != customSessionId)
~ {
~ request.setRequestedSessionId(customSessionId);
~ request.setRequestedSessionURL(false); // Your choice
~ request.setRequestedSessionCookie(false); // Your choice
~ }
~ Valve next = getNext();
~ if(null != next)
~ {
~ request = new WrappedRequest(request);
~ response.setRequest(request);
~ next.invoke(request, response);
~ }
~ }
~ // Unfortunately, Request is not an interface so our wrapper
~ // is a little awkward.
~ static class RequestWrapper
~ extends Request
~ {
~ Request _wrappedRequest;
~ RequestWrapper(Request request)
~ {
~ _wrappedRequest = request;
~ }
~ protected Session doGetSession(boolean create)
~ {
~ Session session = _wrappedRequest.doGetSession(create);
~ if(null != session
~ &&
!_wrappedRequest.response.containsHeader(CUSTOM_HEADER_NAME))
~ _wrappedRequest.response.addHeader(CUSTOMER_HEADER_NAME,
~ session.getId());
~ }
~ // all other methods delegate to _wrappedRequest
~ // be careful to implement them all or things will
~ // act funny
~ }
}
| After reading a little, Tomcat 5x onwards comes with session replication
| capabilities, which means there is some code which you can reference and
| write a valve that intercepts the request as soon as a new session is
| created and before its sent back to the user in the response, an example
| of this being the ReplicationValve which ships with Tomcat.
Yep. At the time, I was unsure of whether or not the session id could be
changed after it was set by the connector. It seems that Valves have
access to the connector's Request and Response objects, which allows
this technique to work.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkfOxzQACgkQ9CaO5/Lv0PAJugCgpCHlxgIPKRhG9ksMHFXZd2wp
nCEAoIYmMllNKE/3SNElgABz+FmcIKau
=XvqJ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
