I have a question about how to switch the way sessionid is passed, by url or by cookie.
My situation is as follows:
We have a an application that is not directly called by a user but via another server.
This other server is called by the user and shows our output as part of the page of
the other server. To maintain session we added a jsessionid as parameter to each link
to the other server. The other server then takes the parameter jsessionid and adds it
as a path extension with ";" to the URL to call our server. This all works, we manage
to maintain session for each user.
At a certain moment the user is completely switching over to our application. That is,
one of the URLs the user can click on his page is directly linked to our server. The
application on our own server just uses normal session handling, ie cookie sending by
default. Whenever our pages are called via the other server, this doesn't matter as
the other server doesn't accept cookies and we added jsessionid in the url explicitly.
Now however we reach a page on our server directly with an existing session we want to
maintain. And we want to continue using cookies for session state. I discovered that
usually session cookies are only set when there is a request.getSession(true) call and
this method discovers that there is no existing session. The first time a page is
accessed on our server we still have the session via URL, but all next pages expect
cookies. What I did is that I added a cookie explicitly in the code of the first page,
hopefully similar in the way tomcat does it:
//all users will pass this servlet
//when identifying themselves
//leave a cookie in this place directly on the client's browser
try {
String contextPath = req.getContextPath();
if ((contextPath == null) || (contextPath.length() <= 0)) {
contextPath="/";
}
StringBuffer buf = new StringBuffer();
buf.append("JSESSIONID=");
buf.append(session.getId());
buf.append(";Path=");
buf.append(contextPath);
String version0Text = buf.toString();
res.setHeader("Set-Cookie",version0Text);
}
catch (Exception e) {
Debug.println("failed to add a cookie on the user browser from
VerifyServlet");
Debug.println(e.toString());
}
I expect that this cookie is overwriting any other already existing cookie. I tested
this in a simple way, and it least it seems that tomcat in this way is able to
maintain the session and that the next pages can continue doing their work.
Now I get to my questions:
1) should I also do this for a version1 cookie or version0 only sufficient? When is 0
used, when 1?
2)currently I am using tomcat 3.1 on linux. I noticed that 3.1 and 3.2 have different
behaviour. In 3.1 if there are both a jsessionid in url and in cookie, the sessionid
in the url gets priority. In 3.2 if they both exist, the one in the cookie gets
priority. The behaviour of 3.2 is awkward. If I at one time get a session cookie in my
browser and then want to start a new session, build up a session via the other server
and then switch back to my server, my server will first recognise the cookie of the
previous session and not use the session that I passed explicitly by URL. I also see
no way like this to invalidate the previous session. The user can start a new session
by calling a page on the other server. Whenever a page on the other server is called,
my server has no access to the user's browser. How can I invalidate the previous
session??
3) What does an invalidate call actually do? If I have a direct connection between
user and my server, does it destroy the cookie in the browser as well, or does it only
invalidate the session in the tomcat-instance's memory and leave the cookie as is.
4)I noticed that 3.2 has the ability to switch off cookie use. This is not what I
need; is there also something that can manipulate whether sessionid by cookies or url
have priority?
Hope someone can help me,
Regards, Jan Kester
