Session management for a RESTful Web Service using Jersey

Question

I am developing a Restful Web Service using Jersey between my Android, iPhone apps and MySQL. I also use Hibernate to map the data to the database.

I have a sessionId (key). it is generated when user Login to the system.

In User class:

public Session daoCreateSession() {
    if (session == null) {
        session = new Session(this);
    } else {
        session.daoUpdate();
    }
    return session;
}

In Session Class:

Session(User user) {
    this.key = UUID.randomUUID().toString();
    this.user = user;
    this.date = new Date();
}

void daoUpdate() {
    this.key = UUID.randomUUID().toString();
    this.date = new Date();
}

When user Sign in to the system successfully, I send this sessionId to the Mobile app client. Then when I want to get some information from database based on the logged in user, I check this Session key as authentication in the REST Services for every request.

For example for the list of project that user is involved in, I use client.GET(SERVER_ADDRESS/project/get/{SessionID})

insetead of client.GET(SERVER_ADDRESS/project/get/{username}).

And if it is not a valid session key, I'll send back to the client a 403 forbidden code. You can also take a look here

The thing is I am not sure about my approach. what do you think about cons in this approach considering for Jersey and a mobile app? I still don't know if the Session key approach is a good idea in my case.

Solution 1

If you want to use SessionId then it should have a validation time, like this:

private static final int MINUTES = 90;

public boolean isValid() {
   return System.currentTimeMillis() - date.getTime() < 1000 * 60 * MINUTES;
}

Solution 2

This is a solved problem - servlet containers like Tomcat already do session management, and can distribute session state to other containers in the cluster either by broadcasting over TCP, or by using a shared data source like memcache.

I'd suggest reading up on what's already available, rather than inadvertently reinventing the wheel. Additionally, this is going to become an incredibly hot table table if your application proves popular. How will you clear out old session IDs?

Comments

[Ali]

Every time that user login to the system, a new session Id will be generated.also this is a temporary Id, it becomes expired after a while.

[DeejUK]

Having every request requiring an operation on the same table would be bad if you're expecting high load. Every login requires a write, every other operation requires a read on a large table that wouldn't be indexed efficiently (UUIDs are bad for that), and then you'll need a background thread to scan over the table and delete expired session IDs, else the table will fill up with useless data. I'd really urge you to look at using Tomcat's inbuilt session management backed by code.google.com/p/memcached-session-manager

[Brill Pappin]

He's actually creating a token system for sessionless requests.