Keep HTTPSession after the user closed their browser

[Guy Yafe]

Hi,
I am writing an application and want to have a session that will be persistent even if the user have closed their browser.
The default HttpSession received by request.getSession() is (AFAIK) based on a cookie named jsessionid and is destroyed after the user closed the browser.
Looking at this session API, it looks like you can change its maxInactiveInterval ,but still it won't help. However I coulsn't find any API that will allow me to set the session as I wish.

The only solution I came up with is ignoring this default session and use my own cookie and my own implemented session. This will allow me to manage my own session and set it to be persistent also when the user close their browser.
Is there a better, less ugly way to do so?
If I call my cookie also jsessionid, will it override the default cookie?

Thanks,
Guy

[William Brogden]

Sessions are managed by the container so don't try to short-circuit that mechanism - leave jsessionid alone.

Yes you can write your own session-like class and handle it independently. Works just fine.

All you really need in the class is a Map but you can add other useful variables. Make the class serializable and create a naming mechanism to get a unique filename for storing the serialized data - or serialize to a database with the unique key.

Bill

[Guy Yafe]

Thank you.
What I have done so far is create my own class named PersistentSession that holds a map from a String to an object an has an API as similar as possible to HttpSession (getAttribute, setAttribute, etc.)
Next I have created a class named SessionContainer that maps a string (session id) to a the above PersistentSession. The session id is the value in a special cookie that I handle. The creation of the value is by UUID class.
Finally, the SessionContainer is a common object for the entire application.
For now I am not dumping this into a DB, and if the application stops, the session disappears. This is because as a newbie I am too afraid of SQL injection, and my DB is read only.

Do you think this scheme is reasonable one for my own session handling?

[William Brogden]

As long as your session ID is unique, sure, why not?

The next step would be to provide some mechanism for discarding the "session" to recover the memory. If the ID string is compatible with file name requirements, you are set to serialize it to disk.

Bill

[Guy Yafe]

My problem of serializing to disk is that I am afraid of SQL injection. I am still not sure how to build a mechanism that will prevent anyone from injection SQL queries into my DB.
For this reason, I only read from my DB but never write into it.

You have raised am important issue which I didn't think of: How to prevent memory overflow.
I think I will keep an expiration date for my sessions and have a daemon that will periodically review all the sessions and remove each session that has expired.

Guy

[Jeanne Boyarsky]

Guy,
Now seems like a good time to learn there is no need to be afraid of SQL Injection. It is one of the easiest security issues to prevent.

When you run any commands against your database, use "binding variables" for all data you didn't directly type in yourself. For example:
insert into session_table(id, text) values (?,?).

Then use a PreparedStatement to set them. That's it! Both of these are good practices to get into in general. Then you don't need to think about it regularly.

[William Brogden]

My problem of serializing to disk is that I am afraid of SQL injection.

Serializing to disk has nothing to do with a database. Java objects are frequently serialized so they can be moved around and the process is quite fast.

Here is a code fragment example where f is a File created using a unique Id for this user and utM is a "model" class for the user's data.

   ObjectOutputStream oos = null;    
   try {
     oos = new ObjectOutputStream( new FileOutputStream( f ) );
     oos.writeObject( utM );
     oos.close();
   } catch(IOException e){
     System.out.println( e.toString() );
   }

Note that after this runs, the current state of the utM object is saved on disk while the utM object remains in memory.

Bill

[Guy Yafe]

Thank you for your answers. I wasn't familiar with prepared statements and haven't thought that dumping an object would be easily safe.
Now that these are implemented, I am much more confident with my site.

Guy

[Luan Cestari]

I would recommend to use a kind of cache system, specially a key-value database as infinispan, redis or others. Using I/O such as writing a file well give you many problem, such as locks, high latency, hard to maintain and etc.

[William Brogden]

Luan Cestari wrote:I would recommend to use a kind of cache system, specially a key-value database as infinispan, redis or others. Using I/O such as writing a file well give you many problem, such as locks, high latency, hard to maintain and etc.

Not really. Each file belongs to a separate user so there is no lock involved. The only maintenance problem would be the same with any system, namely deciding when to discard old sessions. On the time scale of a web application recovering a stored session is practically instantaneous.

Bill

[Luan Cestari]

William Brogden wrote:

Luan Cestari wrote:I would recommend to use a kind of cache system, specially a key-value database as infinispan, redis or others. Using I/O such as writing a file well give you many problem, such as locks, high latency, hard to maintain and etc.

Not really. Each file belongs to a separate user so there is no lock involved. The only maintenance problem would be the same with any system, namely deciding when to discard old sessions. On the time scale of a web application recovering a stored session is practically instantaneous.

Bill

Nice point Bill, I thought sth like that when i posted. Even if there is separated files for each user, you could have a scenario where the user have many tabs pointing to the same URL, it can be worst thinking about using different browsers (I know there is a smaller chance here) (and an forced shutdown could trigger to close all browser, for example). But as always, it will always depends the user cases and non functional requirements that you need to archive. I thought the cache could provide an easy solution for this case but maybe depending the requirements using File can be better.

Regards
Luan

[Raj Chila]

Tomcat has the implementation to serialize the sessions in its work folder (I dont remember if it was during a browser close or a Tomcat shutdown). That could give you a good understanding in implementing your own.

But IMHO, this may pose security issues... Specially in a production grade application.