Restrict user to one session

[Dave Price]

Hey guys:

 

In our Lift application, after the user signs in, an Angular app loads using lift-ng, etc.

 

Now, because our application is using Angular, we expose a %signout URL% that is an EarlyResponse that logs the user out and does a Full(RedirectResponse(“/”)).

 

I am attempting to restrict the users to one active session.   Specifically, if a user logs in using a second session, I would like the first session to get logged out.

 

I found a code example of something similar here:   https://github.com/dpp/starting_point/commit/729f05f9010b80139440369c4e1d0889cac346cf

 

I had to make a few changes but got it mostly working.  However, when I destroy the users first session, that page stays as is.  I believe this is the expected behavior because there is not a session to redirect, etc.  However, I would like to redirect the user to the login screen (“/”).

 

What I am thinking of doing is setting up a comet actor for each user and tracking it with the session information.  Then, when a duplicate session is detected, the comet actor belonging to the first session does this:  partialUpdate(RedirectTo("%signout URL%))

 

Does anyone know if there is a simpler/better way to accomplish this?

 

Thanks!

 

Dave

[Diego Medina]

that's what I would do too if I had to.

That being said, and not knowing anything about your target audience, logging people out because they logged in from a second place is a real , hm, not great :)

I personally go from my laptop to my cell all day long, and having to login again and again all day long because I use two devices would get old pretty fast.

If security is the reason, I would go with gmail's pattern (others do the same), show  small text saying something like "Last account activity: 0 minutes ago" with a link where you can see all the current sessions, and if I see one from a weird place, I can then manually log that one off.

Thanks

Diego

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Diego Medina
Lift/Scala Consultant
di...@fmpwizard.com
http://blog.fmpwizard.com/

[Dave Price]

Thanks Diego!

 

This is a line of business application with fairly stringent security requirements.  E.g. each user has to execute an Access & Use Agreement outlining many restrictions before they can receive an account.  One of which is they are prohibited from sharing their account.  We don’t see this much, but when it does happen it is usually with a user within their same company.  So, the idea behind this approach is an attempt to make sharing ones account more difficult:  if you share your account, when the other party uses it, you get booted.

 

However, I agree, it is not necessarily the best user experience and I do like your suggestion.  Seeing a message about multiple session may have the same impact on the user as getting logged out.  Of course, we could also log when multiple sessions occur in case we need to further investigate. 

 

I appreciate your help and suggestion!

 

Dave

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Diego Medina]

I see, sounds like your use case is very specific and may make sense there.

Thanks!

Diego

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Antonio Salazar Cardozo]

Awesome suggestion for better UX there Diego. 💯💯💯💯

And Dave, that extrapolation of letting the user know + tracking it

so that you can keep an eye out for violations sounds like the perfect

compromise—if you can convince others, of course :)

Great stuff!

Thanks,

Antonio

[Colin Bester]

I know I am late to the party, but following up on Diego's suggestion, I have found that displaying such information is an added deterrent when they know their actions are captured/logged.