Under What Conditions Is a Jsessionid Created

Under what conditions is a JSESSIONID created?

JSESSIONID cookie is created/sent when session is created. Session is created when your code calls request.getSession() or request.getSession(true) for the first time. If you just want to get the session, but not create it if it doesn't exist, use request.getSession(false) -- this will return you a session or null. In this case, new session is not created, and JSESSIONID cookie is not sent. (This also means that session isn't necessarily created on first request... you and your code are in control when the session is created)

Sessions are per-context:

SRV.7.3 Session Scope

HttpSession objects must be scoped at
the application (or servlet context)
level. The underlying mechanism, such
as the cookie used to establish the
session, can be the same for different
contexts, but the object referenced,
including the attributes in that
object, must never be shared between
contexts by the container.

(Servlet 2.4 specification)

Update: Every call to JSP page implicitly creates a new session if there is no session yet. This can be turned off with the session='false' page directive, in which case session variable is not available on JSP page at all.

Where is JSESSIONID stored?

To Start off the JSESSIONID is stored in a cookie. If cookies are turned off, you have to get into url rewritting to store the jsessionid in the url. There is nothing else about the session in cookies. There is nothing stored in a session until one of the following happens:

1. Authentication in the container
2. request.getSession() or request.getSession(true) is called

Once that happens, you can store information in the session. When calling request.getSession(), it returns HttpSession. The HttpSession implements serializable. Once this object exists, when the request ends, this object is serialized. Every container gives different ways on how to store the HttpSession serialized object. By default most servers do this in memory. Most containers will give you multiply choices to pick on how the HttpSession objects can be serialized (memory,disk,database). Most containers will also give you a way to customized and create our own way to serialize the HttpSession.

The Servlet spec by default does not really give you a way to peek into sessions and get a list of session id's or the data associated with it. It is a huge security risk.

If you want to get that list of session id's and the information associated so you can look, will are going to have to write code. There are multiply ways to do this. Some examples are:

1. Implement javax.servlet.http.HttpSessionListener and store the jsessionid to the database
2. Implement javax.servlet.http.HttpSessionAttributeListener and store the key/value pair in the database with the session id

When implementing any of the above interfaces, you will not be able to retrieve the username from the authentication, unless you store the information in the session. You can add the two listeners to any web application without affecting the original war/ear files behaviour.

By default the app servers make it hard to get the information you are looking for, but with a little bit of coding, you can circumvent it.

Creating a new JSESSIONID after authentication

This looks a lot like the session fixation problem I solved for Liferay 5.2.5 a long time ago. The solution consists of creating a custom Tomcat Valve that will force a new session ID. So the solution isn't really specific for Liferay and is dependent on if you use Tomcat or not.

I suspect it shouldn't be too difficult to adapt my old solution to a newer Liferay/Tomcat combination. You can find the necessary information about my solution in my old and currently unmaintained blog (if I only had more time...): Fixing session fixation in Liferay

jsessionid is saved and used even after reboot\re-installation of the service

In answer to your questions:

1. Tomcat's session Manager will serialize session data and save it to a file to persist it across restarts. You can disable this.
2. Tomcat's SessionId Generator determines the exact way the id is created.
3. Here a good answer for when session ids are created: Under what conditions is a JSESSIONID created?
4. If your goal is to invalidate sessions after a Tomcat restart, you can do this by disabling session persistence.
5. Typically a user would want to be considered "logged in" until they click a "log out" link or button in your application. You can also adjust the session expiration time if you want the session to expire after a period of inactivity. How exactly this should work is up to you and depends on your application's use cases.

Extract JSESSIONID in REST after login

If you have a http request object you can get hold of the associated session. Once you've got the session you can get its id

request.getSession(true).getId()

Passing true to getSession causes a new session to be created if one does not already exist.

---

Related Topics