Knute Snortum wrote:Well, from the little you've given us, I would guess something like this:
WRONG!!!
You don't own jsessionid. The server owns it. A web application should
never mess with or cache jsessionid (it can change without warning). Nor should a web client. The jsessionid is passed to the client in a cookie and should be returned with a cookie on the next submit (which most clients do automatically anyway), but the response might contain a completely different jsessionid for the next request to use.
NO SERVICEABLE PARTS INSIDE.
The jsessionid contains absolutely no data about the session or the client. It simply a semi-randomly generated value created by the web application server as a key for the server's internal Map of HttpSession objects. It's used by the server to look up the HttpSession that corresponds to the submitter so that the server can distinguish between one user and another. It should not be used for any other purpose. And, repeating myself, the server can and often will change this key to a completely different value while a session is active.
If you want to pass data from your webapp to a web client and back again, use a regular cookie. DON'T use jsessionid. You have been warned!
Oh, and incidentally, if you are using the J2EE/JEE standard container security system to handle logins (and you almost always should), then your login userid can be determined by the web application at any time by using the request getRemoteUser() method.