Re: Using a custom method of session-id propagation
Christopher Schultz wrote: | The problem with both cookies and session id's in the URL is that we | develop applications for use on cellphones. Cell network operators are a | bunch of not-so-nice-people who sometimes feel the need to screw up HTTP | traffic in their gateways, e.g. by messing with cookies and session ids. Can you give us an example of what happens to your JSESSIONID cookie? At the moment, nothing, but that can change any time, that's why we want to have at least the option of using a different header. We've had operators mess with all kinds of standard HTTP headers so we try to have a fallback for these. | There is no guarantee that the cookies that arrive on the handset are | the same as the ones that have been sent out from our servers. Sometimes | cookies go missing, standard HTTP headers are mutilated, etc. That sucks. Is it selective? I mean... do you always get the GET line correctly, just the others are hosed? Depends, a while back everything got messed up on a certain local operator. They even replaced the user-agent with something incorrect. (basically, every request looked like it came from an OperaMini browser). Sincerely, Tom - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using a custom method of session-id propagation
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. but I am still a little curious as to why Tomcats generated session id is not adequate, is it purely because you can't get at it early enough? 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. 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. ||You can then persist it in a database or do whatever you want with it. Maybe these can help a little: http://www.onjava.com/pub/a/onjava/2004/11/24/replication1.html?page=last http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html Peter Tom van Wietmarschen wrote: L.S., I was wondering if it is possible to write a custom method of propagating the session ID between HTTP requests. Specifically: we want to store the session id in a X-ourcompanyname-sessionid header (we use a custom http client so we can modify that to send the sessionid back in a header). The reason for this is that we have to deal with clients that are using mobile data connections, and mobile phone operators sometimes feel the need to mess with a clients cookies and sessions as well as doing other kinds of nasty things in their proxies. Non-standard headers are usually left alone. I've been looking at a way to do this but I can't find a solution, filters seem to be too late in the chain: a request object is already created and 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. Does anyone known if there is a way to write my own handlers for retrieving and setting the current sessionid and have tomcat use that instead of looking at the requesturl or cookies ? Sincerely, Tom van Wietmarschen - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using a custom method of session-id propagation
-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
Re: Using a custom method of session-id propagation
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. but I am still a little curious as to why Tomcats generated session id is not adequate, is it purely because you can't get at it early enough? Yes, the session id itself is adequate, I don't want to change that at all, nor do I want to change the session manager. What I want to change is how the session id is communicated to the client and back. Basically, I want to change the object that retrieves the session ID from the HTTP request and feeds it to the session manager. (storing the session id in an additional header in the response is no problem) The problem with both cookies and session id's in the URL is that we develop applications for use on cellphones. Cell network operators are a bunch of not-so-nice-people who sometimes feel the need to screw up HTTP traffic in their gateways, e.g. by messing with cookies and session ids. There is no guarantee that the cookies that arrive on the handset are the same as the ones that have been sent out from our servers. Sometimes cookies go missing, standard HTTP headers are mutilated, etc. Our experience is that the custom X-headers are left alone, so we want to use a custom header to send and retrieve the session ID. 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. ||You can then persist it in a database or do whatever you want with it. I've looked at the Tomcat API doc's and it seems to me the sessionmanager itself is not responsible for retrieving the session id, the session id is fed to it by someone else. (See 'findSession' in ManagerBase). Also, sending the session id back to the client is not the problem I can use a filter to do that. The problem is that if the client sends the session ID to the server in a custom header, Tomcat needs to pick up that session id and use that when calling findSession. So who is calling findSession and is it something I can easily replace ? Furthermore, as an additional difficulty, we only use sessions in a subset of our applications, so it would be preferrable if this is something we can enable on a per-application basis. I hope this clarifies what I'm trying to do. Sincerely, Tom -- **Tom van Wietmarschen** Software Engineer Service2Media B.V. Vreelandseweg 7 1216 CG Hilversum Capitool 41 7521 PL Enschede Tel +31 (0)35 626 46 12 Fax +31 (0)35 626 46 13 www.service2media.com http://www.service2media.com - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using a custom method of session-id propagation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom, Tom van Wietmarschen wrote: | What I want to change is how the session id is communicated to the | client and back. Basically, I want to change the object that retrieves | the session ID from the HTTP request and feeds it to the session | manager. That object /is/ the CoyoteAdapter, which is why I suggested it originally. See my most recent post for a less intrusive possibility. | The problem with both cookies and session id's in the URL is that we | develop applications for use on cellphones. Cell network operators are a | bunch of not-so-nice-people who sometimes feel the need to screw up HTTP | traffic in their gateways, e.g. by messing with cookies and session ids. Can you give us an example of what happens to your JSESSIONID cookie? | There is no guarantee that the cookies that arrive on the handset are | the same as the ones that have been sent out from our servers. Sometimes | cookies go missing, standard HTTP headers are mutilated, etc. That sucks. Is it selective? I mean... do you always get the GET line correctly, just the others are hosed? | The problem is that if the client | sends the session ID to the server in a custom header, Tomcat needs to | pick up that session id and use that when calling findSession. So who is | calling findSession and is it something I can easily replace ? Again, see my earlier post. | Furthermore, as an additional difficulty, we only use sessions in a | subset of our applications, so it would be preferrable if this is | something we can enable on a per-application basis. The solution I proposed can be enabled for all applications and it will not interfere with normal operations. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfO0q0ACgkQ9CaO5/Lv0PAyPQCfWaRX7x+21dHz4pIFzjbEXS9c hIQAn3S4yV8pnKCoTwu+wbRclFkkVZ36 =lYfQ -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]
Re: Using a custom method of session-id propagation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom, Tom van Wietmarschen wrote: | I've been looking at a way to do this but I can't find a solution, | filters seem to be too late in the chain: a request object is already | created and 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. Actually, you /can/ use a filter of your own design if you'd like. WHen you do that, though, you have to give up the container's session management, which makes it /your/ problem to do everything including distributing sessions around a cluster, etc. Although I'd recommend against it, here's what you do: Write a filter that takes the request and looks for the X-whatever header you were talking about. If the header is present, you take the session id and look up the session in your (own) session storage area (probably a Map of some kind... you might want to check out commons-collections for some nicer maps than the basic Java API). Once you have the session, create a wrapper for your HttpServletRequest (that you write yourself) that ties the as-yet-unrelated session to the original request (through the request wrapper). Once again, you will have to do everything for the sessions, etc. Don't forget that in order to be spec-compliant, you'll need to send session event messages, etc., expire the sessions as appropriate, etc., etc., etc. | Does anyone known if there is a way to write my own handlers for | retrieving and setting the current sessionid and have tomcat use that | instead of looking at the requesturl or cookies ? Looks like org.apache.catalina.connector.CoyoteAdapter is responsible for determining the requested session id. If you were to override the parseSessionId method, you could probably get the id from the request fairly easily, although parseSessionCookiesId also gets called. You might even want to add your own method as another option, say, after the other two. See the postParseRequest method in that class. I can't seem to find the place where Tomcat sets the JSESSIONID cookie on the way out, so you'll either have to find that yourself or write a filter to add it at some point. Hope that helps, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfNZDUACgkQ9CaO5/Lv0PBDogCeOloU9p0jMtSZ2YAyCyf8hfDX Df0AnAvm41pSR8ZORJoc41HpurRqWLn7 =7QkG -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]
Re: Using a custom method of session-id propagation
The problem is that the server needs to be the one generating the session id for a number of reasons, i.e.: ensuring it is always unique and set correctly, and its best left that way... so I think you're walking down a dark alley and its not likely that the API would ever allow this as it opens up untold security holes. Furthermore, without using a URL or cookies to transport the id how do you propose that the server should communicate it to an agent? ...not sure if XML over HTTP / SOAP could potentially provide a solution, but then again you have similar problems with proxies and firewalls etc. in any event. Good luck, Peter Tom van Wietmarschen wrote: L.S., I was wondering if it is possible to write a custom method of propagating the session ID between HTTP requests. Specifically: we want to store the session id in a X-ourcompanyname-sessionid header (we use a custom http client so we can modify that to send the sessionid back in a header). The reason for this is that we have to deal with clients that are using mobile data connections, and mobile phone operators sometimes feel the need to mess with a clients cookies and sessions as well as doing other kinds of nasty things in their proxies. Non-standard headers are usually left alone. I've been looking at a way to do this but I can't find a solution, filters seem to be too late in the chain: a request object is already created and 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. Does anyone known if there is a way to write my own handlers for retrieving and setting the current sessionid and have tomcat use that instead of looking at the requesturl or cookies ? Sincerely, Tom van Wietmarschen - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
