How to make Single user login in MVC 4 applictaion

Question

I am implementing an application where there is a mechanic for each machine in the company using the application. I'm trying to implement a user policy whereby if user is in a role "Mechanic" -- with username Machine1, and is logged in for that machine, only one user can be logged at at the same time with the Machine1 username for the company. If someone else tries to login with the same username, it should be blocked and informed that there is already logged in user. When the session timeout expires i should log out the logged in user and free the login to be used. The same happens when the user logouts by himself. I'm trying to build this on asp.net MVC 4 application.

I've thought of using the SessionId, UserId and IsLoggedIn boolean in the database. But in this case i need to change the logged in flag on session timeout in the MVC app to write in the database, which seems overkill if many users are logged in.

What would the implementation be like? What methods or attributes should I be using to handle the session management in the database ?

FYI

I have made my own method where i check if the user is logged in, here it is:

public static bool ValidateUser(string username, string password, string companyName)
{
    int? companyId = myRepository.GetCompanyId(companyName);

    int? userId = companyId == 0 ? null : myRepository.GetUserId(username, companyId);

    if (userId.HasValue && userId.Value != 0)
    {
        var userKey = Security.GenerateUserKey(username, companyName);
        return WebSecurity.Login(userKey, password);
    }
    else
    {
        return false;
    }
}

Here in this method i can check somehow if the session id is the same as in the database.

Answer 1

The crux of the problem for this issue is knowing when the user logged out to allow the next user in with the same name. I do not know of a precise way to do this in a web application, but here is a method that can approximate knowing when the user logged out by controlling how long their login lasts. For testing this I set the timeout to 1 minute so I could quickly test going between the different users with the same user name. You control this through the web.config.

<forms loginUrl="~/Account/Login" timeout="1" slidingExpiration="false" />

Notice that I set slidingExpiration to false to know precisely when they will be logged out. If you use a sliding expiration there is no way to predict when the logout actually occurred because you cannot count on the user physically logging out.

To keep track of what user is currently logged in I used a MemoryCache and used its expiration policy to automatically track the time for me. Here is a simple helper class I wrote to manage this.

public class UserManager
{
    public static bool IsLoggedIn(string username)
    {
        ObjectCache cache = MemoryCache.Default;
        return !string.IsNullOrEmpty(cache[username] as string);

    }

    public static void SetToLoggedIn(string username)
    {
        ObjectCache cache = MemoryCache.Default;
        CacheItemPolicy policy = new CacheItemPolicy();
        //Expires after 1 minute.
        policy.AbsoluteExpiration = new DateTimeOffset(DateTime.Now.AddMinutes(1));
        cache.Set(username, username, policy);

    }
}

Notice that I used AbsoluteExpiration and set the timeout to the same length I set for forms authentication. This clears the object from the cache in 1 minute from the time it is written. That way I can just check for the presence of the object in the cache to determine if the allotted time for a users login has passed. I use the username as the key for the cached object since we are checking that one user with that username is in the system at any one time.

Now we just change our login action to look like this.

    [HttpPost]
    [AllowAnonymous]
    [ValidateAntiForgeryToken]
    public ActionResult Login(LoginModel model, string returnUrl)
    {
        if (ModelState.IsValid )
        {
            if (UserManager.IsLoggedIn(model.UserName))
            {
                ModelState.AddModelError("", "A user with that user name is already logged in.");
                return View(model);
            }
            if (WebSecurity.Login(model.UserName, model.Password, persistCookie: model.RememberMe))
            {
                UserManager.SetToLoggedIn(model.UserName);
                return RedirectToLocal(returnUrl);
            }
        }

        // If we got this far, something failed, redisplay form
        ModelState.AddModelError("", "The user name or password provided is incorrect.");
        return View(model);
    }

I tested this out on an MVC 4 application using SimpleMembership and it works. The only downside I can see with this approach is that you will require an absolute timeout instead of sliding. Getting the correct setting for the timeout will be critical to reduce frustration of users being logged out at specific intervals and to minimize the time another user will have to wait to get logged in.

Answer 2

I've done similar things and they are always involved. You need a lock or semaphore of some kind. This is best done in the db side with repo actions.

I'm not sure this should count as an actual answer since I'm not giving you an implementation so much as approaches.

approach 1:

Once authenticated, keep the user row-locked with an exclusive lock. Once your user logs out, the repo (EF) connection is recycled, the exclusive lock is freed.

You will need to use a try-catch on your login process (and possibly use a timeout) as that will be the result of a login attempt.

approach 2:

once logged in, lock the user by taking away login permission:

MembershipUser muUser = Membership.GetUser(strUsernameToActOn);
muUser.IsApproved = false;
Membership.UpdateUser(muUser);

note: this method requires maintenance in assuring that the user is unlocked after logout. This can be tricky. You may choose to use a destructor action or a background daemon that checks the last time this user was actually active.

approach 3:

have a logged in timestamp on your user record. Update this timestamp everytime the user hits the db for any action.

During login, check the timestamp with a reasonable offset to watch for allowable logging in.

On logout, blank the timestamp.

approach 4

use a singleton class: Upon logging in, create an instance with the constructor adding the user's ID (or name) to a static list of users not allowed to login.

Use a destructor action for removing the user (or go by the existence of an instance of the singleton).

Do not allow any logins for users part of the static - singleton driven list.