Disabling Multiple login of a user

I have an application where in a user Id should not be used by more than one person to log in at the same time.

What I mean is that at any given point of time, if a person is logged in to the application, with say user id "myself002", then another person should not be able to log in using the same credentials.

This applies if the person trying to log in from another machine or the same person is trying to log in the application using two different browsers.

One approach to achieve this is keeping a flag in the DB and before letting the user gain access to the application, check the flag.

Since I am using LDAP for authentication, this approach would be a bit costly in terms or performance. Also my client does not want to store any session information in the DB or LDAP.

The reason it's tricky is because my application would be running on clustered Application Server environment, and a user would be re-directed to any application server which is comparatively free.

I am thinking if somehow we can get the session Id created by WebLogic Application Server. Since each user would be associated with a unique session Id, we may then be able to control who is logging in. Also we may also be able to invalidate the session.

Another approach is to have a listener which listens on each request and puts all the active sessions in a HashMap or Hashtable with the key as username and stores this into the DB. When the session is invalidated, the Listener clears the entry from the Collection. Thus we would have DB as the centralized place for checking the active sessions and authenticating users.

Can someone help me on the same? Its' kind of urgent, so any help would be a great help.

I hope I am clear on what problem I am facing and what I want.

[1818 byte] By [saurabh.mathura] at [2007-11-27 10:29:41]
# 1

Hi,

... Another approach is to have a listener which listens on each request and puts all the active sessions in a HashMap or Hashtable with the key as username and stores this into the DB. When the session is invalidated, the Listener clears the entry from the Collection. Thus we would have DB as the centralized place for checking the active sessions and authenticating users...

I would say You don't need a listener as far You should already have login process and better to do all checks there. The second thing is DB it is better not to use DB here. But it is a matter of what exectly distributed model is implemented.

Hope it helps :)

_Dima_a at 2007-7-28 17:58:55 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 2

>

> I would say You don't need a listener as far You

> should already have login process and better to do

> all checks there. The second thing is DB it is better

> not to use DB here. But it is a matter of what

> exectly distributed model is implemented.

>

> Hope it helps :)

No. What you suggested would not work because my application is on a cluster and in a clustered environment you can not control where the request is directed to. To prevent this, I need to have the session information of all the users. This is possible in two ways:

Either I share the session information of all the Application Servers with the remaining Application Servers or I keep a record of all the active sessions.

Does it makes the problem more clear?

saurabh.mathura at 2007-7-28 17:58:55 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 3

There are many options. It depends on scale, load and business requirements. Often, DB is a bottle nec of an application. Thus, one needs to cache all sessions [and users] to boost performance. One can use MQ, JNDI or dedicated RMI service for this task.

But, if DB is not overloaded it could be reasonable to use the DB for session check as well.

_Dima_a at 2007-7-28 17:58:55 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 4

Have you tried the Observer/Observable types?

Manuel Leiria

manuel.leiriaa at 2007-7-28 17:58:55 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...