14

Is it possible to allow only one concurrent login per user in ASP.NET web application?

I am working on a web application in which I want to make sure that the website allows only one login per user at a time. How to check that the current user already logged in or not?

Please suggest proper login method by which we can handle this problem. I think we should use SQL Server session state to handle this problem. What do you suggest?

I thought of one solution for it. We can do something like:

  1. When the user logs into the system then we insert session id in user column. (We will use database session so that we can get all session related data like isexpired, expiredatetime etc easily).

  2. When the same user tries to login a second time then we will check for that session id column and check that session is already expired or not. If session is not expired then we will not allow user to login.

  3. Update user session ID every time when user logs out.

Please suggest whether this is the proper way or not.

Dale K
  • 25,246
  • 15
  • 42
  • 71
Hiren Dhaduk
  • 2,760
  • 2
  • 19
  • 21
  • What kind of authentication are you using? standard Forms Auth or something customized? – Markus-ipse Jul 07 '13 at 19:55
  • we created login form and made store procedure to check user login credentials . we did't used any membership features . – Hiren Dhaduk Jul 07 '13 at 19:58
  • save a `isLoggedIn` property and when you authenticate raise that to `1`, when logout to `0`, if session ends in the meanwhile you need to reset all, `Membership` uses `LastLoginDate` and you can play a bit with it. – balexandre Jul 07 '13 at 20:11

6 Answers6

9

Please refer to:

When the same user ID is trying to log in on multiple devices, how do I kill the session on the other device?

Out of the box, .NET does not support this. .NET allows for concurrent log-ins, as I'm sure you're aware.

I had this same exact requirement, and came up with a pretty slick solution, demonstrated in the link above. In a nutshell, my requirement was to only have one user log-in happening at one time. If that same user ID tried to log in elsewhere, then it killed the session for the first log-in by checking for an existing log-in under a different Session ID (this enabled the user ID to be logged in from multiple instances of their web browser on their computer [same Session ID], which is common, but not from a different computer [different Session ID] (possibly due to someone that stole their credentials, for example)). Through modification of the code you could probably change the behavior of this - i.e., prevent the second log-in attempt instead of killing the first log-in that's already active and in use.

Of course, it may not fit 100% to what you're needing, so feel free to modify it to fit your needs.

Community
  • 1
  • 1
Mike Marks
  • 10,017
  • 17
  • 69
  • 128
5

You can create a cache entry per user and store their session ID in it. Session ID will be unique per browser session. In your login page, you can create that cache entry when they successfully login:

if(Cache.ContainsKey["Login_" + username])
    // Handle "Another session exists" case here
else
    Cache.Add("Login_" + username, this.Session.SessionID);

(Code typed in textbox without syntax check. Assume "pseudo-code".)

In global.asax you can then hook into the Session_End and expire that cache entry of the user. See this for the global.asax events.

if(Cache.ContainsKey["Login_" + username])
    Cache.Remove("Login_" + username);
Tombala
  • 1,660
  • 9
  • 11
  • Why use `Cache` instead of `Application`? Or just global static `Dictionary`. – abatishchev Jul 08 '13 at 03:29
  • 3
    @abatishchev Cache is managed better and can be made to be synced across web farms or multiple threads with load balancing, etc. The others (static or application) are only in the process and won't guarantee a singleton object in those cases. But, if the case is not requiring that, you can use a static dictionary or application object. – Tombala Jul 08 '13 at 15:52
  • 1
    Cache is ***not distributed***, only in web server, not in webfarm. ***Distributed cache*** is for all webfarm. – Kiquenet Jun 22 '16 at 10:23
  • @Kiquenet You're right. I was thinking of Session state. Caching is not distributed. I should know. I have used memcached and other solutions to get around this limitation. :( Have a Klondike bar! – Tombala Jul 11 '16 at 19:50
  • @Kiquenet: You can use a distributed cache solution like http://memcached.org/. Then in my answer, replace everything referencing "Cache" with memcached. Or as an alternative, as the other answer said, you can use a table to manage it but be careful if you have a high traffic website. Locking/blocking could become an issue. Memcached or similar is probably a better performing way to do it but involves more setup. Klondike bar is an ice cream treat in the USA. Their commercials show someone doing something nice, and then says "Give that man a Klondike bar!" – Tombala Aug 01 '16 at 14:02
2

You could add a flag column in the user table that indicates that a user is currently logged in.

When a users attempts to log in you check the flag if it's true (that users account is already currently used) then you don't allow the new user to log in, if the flag is false the users is allowed to log in as there account is not being used by anyone else at this time.

Be aware though that unless the uses actively logs out, you cannot know when the users moves on to something else (goes to different website or closes the browser, etc.) so you need to set some kind of session timeout that will automatically log out the user if there are no new requests within a specified time period.

This means that if a users closes his/her browser and try to log in on a mobile device for example, he/she will be unable to log in until your specified session timeout runs out, so give the timeout a bit of thought as you don't want the user to get logged out to quickly (if he/she is reading a long page, etc.) and you don't want the users to be unable to log in on another device for hours if he/she forgot to log out before leaving the home.

Markus-ipse
  • 7,196
  • 4
  • 29
  • 34
  • 1
    I think you may to do not want to persist such data but keep it in memory (I'd use global static dictionary). You care while application is alive. Once it goes away, you don't care anymore, so don't need to persist it. Also image an issue with coming back user and properly not-cleared database record. – abatishchev Jul 08 '13 at 03:32
  • 1
    limitations: global static would not work in web farm scenarios. if the sessions are sticky, another session could be started and if it "sticks" to a different server in the farm, both would be allowed. without sticky sessions, the global statics would not be updated on the other servers. global statics would also have to be insulated against race conditions, especially if the application is prone to "land-grab" login surges where a flood of users need/want to log in at the same time (e.g. hot event ticket registration starts at specified time) – BrianCooksey Apr 27 '16 at 20:06
1

The login credentials are stored on the cookie, so to know if the user is logged in you need to keep this informations on server, prefered on a database because the database can be the only common place among web garden or web farm.

What you can keep, is on a table, that the user A is logged in or not, flag it that is logged out, maybe last user interaction to have a timeout, etc...

So let say that the User A, is logged in, then you open a flag on the database for that user, that is now logged in, and if is try to logged again, you keep him out. To make this work you need to either say to your users to log out, or to keep a time out, similar to the time out of the credentials.

Aristos
  • 66,005
  • 16
  • 114
  • 150
1

If You are using identity system this link will help you how to single user login on multiple device. Prevent Multiple Logins in Asp.Net Identity I have tried they work fine in my Asp.net Mvc Project.

Hamza Shafiq
  • 69
  • 1
  • 13
  • It seems a good work around but it could be a mess if the site has numerous users requesting frequently to server as the server will be verifying the `SecurityStamp` each time a request is made. – Jamshaid K. Jan 14 '19 at 12:42
0

Solution can be this way:

Add new column in your login table GuidCode.
Step 1 : When logging in check if the GuidCode in database is null.
Step 2 : Update GuidCode by new guid and also store it in the session.
Step 3 : If it is not null then take guid from the session and compare with database GuidCode value.
Step 4 : If it is same then allow login:

CKE
  • 1,533
  • 19
  • 18
  • 29
Praveen Yadav
  • 1
  • 1