• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

User who is logged in simultaneously from different browser ... how to forcely logout the first user

 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have one login page which is built with JSF <---> Spring <----> PostgreSQL
If a user is logged in from 2 different browsers(with same user name) then the first user need to be logged out to the login page if he is doing any requests...
how this can be achieved ...
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to the JavaRanch, Babu. We'd prefer that you use your actual last name instead of just an initial letter, though.

J2EE does not maintain a continuous connection between client and server (actually, no HTTP-based system does). So you can't sever that (non-existent) connection to force a logout.

The only way to log out is to discard your security context, which generally means to destroy your HTTPSession object.

Probably your best bet would be to keep a list of all logged-in users, and when an attempt is made to login a user ID that's already listed as logged in, you'd have to set some sort of indicator that causes the next request from the old location to be redirected to a logout process. Only the server or the logged-in user can log out the user, no other user can do so (safely and portably, anyway!). So you can't do an immediate logout, only a scheduled one.

In actual practice, it's more common to reject the second login instead of forcibly terminating the first login, since there may be work in progress that should be saved over on the original user login. Some systems have been set up to force out an existing login, but they normally ask permission first, so that there will be an option to save whatever that work in progress was.
 
Babu Raj K R
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:Welcome to the JavaRanch, Babu. We'd prefer that you use your actual last name instead of just an initial letter, though.

J2EE does not maintain a continuous connection between client and server (actually, no HTTP-based system does). So you can't sever that (non-existent) connection to force a logout.

The only way to log out is to discard your security context, which generally means to destroy your HTTPSession object.

Probably your best bet would be to keep a list of all logged-in users, and when an attempt is made to login a user ID that's already listed as logged in, you'd have to set some sort of indicator that causes the next request from the old location to be redirected to a logout process. Only the server or the logged-in user can log out the user, no other user can do so (safely and portably, anyway!). So you can't do an immediate logout, only a scheduled one.

In actual practice, it's more common to reject the second login instead of forcibly terminating the first login, since there may be work in progress that should be saved over on the original user login. Some systems have been set up to force out an existing login, but they normally ask permission first, so that there will be an option to save whatever that work in progress was.





What i thought is what you explained...but my question is .. a you said as BEST BET ...how to keep the users who is already logged in .. with out using database connectivity ie; when a user is logged in we are updating the status and some more details in the db.. for each login we cant check whether how many users are logged in .. which is not a best practice.. so what i m thinking is to do something in the session base..please update....
 
Tim Holloway
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That sounds like a somewhat different problem.

Because of the immediacy of the HTTP request/response paradigm, a user cannot (reliably) hold onto a database connection or transaction for an extended period of time. However, in the case of a workflow consisting of multiple views (and extended transaction), you may have to do one of 3 things:

1. Break the transaction down into separately managed parts.

2. Lock the affected resources for the life of the extended transaction.

3. Ignore any other actors and proceed onwards, letting them handle the consequences.

Solution 2 is the least common, since it can lead to deadlocks. Solution 3 has the drawback that unless you're careful, the consequences don't get handled properly.

If you're using a sufficiently powerful database and an extended transaction driver/environment, some or all of the issues involved in extended transactions may be automatically handled for you. One of the things you can do if that isn't enough, or isn't an option is to provide your own interlocks as well.

You can set up a hashtable at application scope where the keys are user IDs and make entries into it (using synchronized resources). And/or you can set up a similar resource access control facility if you're more interested in limiting specific resources instead of users. Things that can help are:

A) A servlet filter. If you're using container-managed security, the HttpServletRequest userId will contain the userID (or null, if the user isn't logged in).

B) A session listener. This allows you to remove a user from the control tables when they're logged out (whether explicitly or when the session times out).
 
Babu Raj K R
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:That sounds like a somewhat different problem.

Because of the immediacy of the HTTP request/response paradigm, a user cannot (reliably) hold onto a database connection or transaction for an extended period of time. However, in the case of a workflow consisting of multiple views (and extended transaction), you may have to do one of 3 things:

1. Break the transaction down into separately managed parts.

2. Lock the affected resources for the life of the extended transaction.

3. Ignore any other actors and proceed onwards, letting them handle the consequences.

Solution 2 is the least common, since it can lead to deadlocks. Solution 3 has the drawback that unless you're careful, the consequences don't get handled properly.

If you're using a sufficiently powerful database and an extended transaction driver/environment, some or all of the issues involved in extended transactions may be automatically handled for you. One of the things you can do if that isn't enough, or isn't an option is to provide your own interlocks as well.

You can set up a hashtable at application scope where the keys are user IDs and make entries into it (using synchronized resources). And/or you can set up a similar resource access control facility if you're more interested in limiting specific resources instead of users. Things that can help are:

A) A servlet filter. If you're using container-managed security, the HttpServletRequest userId will contain the userID (or null, if the user isn't logged in).

B) A session listener. This allows you to remove a user from the control tables when they're logged out (whether explicitly or when the session times out).




Thanks Tim

I had made it... i will explain you, if any defect or correction please let me know

I have one filter and a session listener..
Filter --> For any request we need to check whether the user is logged in or not, if not logged in we will redirect him to the login page
Listener --> For identifying destroyed sessions

I have 2 ArrayList
1) For keeping active session details
2) For keeping inactive session details
Here i am keeping one pojo for keeping session details, with variables are loginname, sessionid, loginid etc

When the user is logging in i will check whether the same loginname is present in the active list. if yes then that session details will be added to the inactive list and removed from active list and the new session details will be added to the active list.

When a hit comes from the user i will check whether the session details is in the inactive list, if yes then call session.invalidate(). since its in my control we can do anything in that part

When the session is destroyed then remove the session details from the active list

A class is mainataining for this purpose .. both array lists are static...sessionAdding, sessionRemoving, sessionInvalidating methods are synchronized(need to think of using vector,but whether synchronized will really make problem, say if 50000 users are logging in)

Performance wise we need to check how good is this approch, since for every request, filter is calling..

Please update me if this has any problem...
 
Tim Holloway
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, the biggest problem I have with this idea is that it's based on a Do-It-Yourself security system. I rant frequently on this topic, because designing and implementing a security system is hard work that could be better spent on the business function, it's extra maintenance costs, and - most importantly - in over 10 years working with J2EE, I've never actually encountered a DIY security system that was actually secure. Most of them are pretty darned insecure, in fact. Including some high finance and military ones I've seen.

Ignoring my own personal obsession, however, I do have some concern that the application logic seems to require all this rigamarole regardless of what application function you're actually performing. I'd be looking more at a targeted approach myself.

I wouldn't worry too much about the sync overhead for Vector. It's likely to be lost among the overhead for more complex functions. The only caveat is that you shouldn't attempt to single-thread through really long vectors - use a synchronized hashtable for that kind of stuff.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic