CODEWITHSUNDEEP
asp.net-mvcsession-variables
chiapa
chiapa

Reputation: 4412

Storing logged user data

Working on an MVC project, the user inserts its credentials in a login form. I get all the other information about that user through a webservice and am currently storing it like this:

var result = client.getUser(gui);
name = result.users.ElementAt(1).name;
...

...

Session["userCode"] = userCode;
Session["password"] = password;
Session["userName"] = name;
Session["userEmail"] = email;
Session["creationDate"] = creationDate;
Session["phoneNumber"] = phone;

Throughout the app, whenever I need, I access these variables if I need the data in them. Since I'm working on a new project that only has about 5 pages, I wonder if I'll be accessing them like this even when the project has dozens of pages or if I shouldn't use session variables at all.

Is there a better way to store this logged user data?

Upvotes: 2

Views: 3404

Answers (1)

trailmax
trailmax

Reputation: 35106

First things first: Don't ever store user password in a session - horrible security issue!

If you are building your application just now, I highly recommend using Identity framework. There you can add Claims to user identity. List of claims is like a dictionary of string to string. And you can look up claims whenever you'd like.

So you can add claim to user with their phone number, email and creation date easily, then have extension methods to get this data out:

public static bool GetEmail(this ClaimsPrincipal principal)
{
    if (principal == null)
    {
        return false;
    }

    var emailClaim = principal.Claims.SingleOrDefault(c => c.Type == "Email");

    if (emailClaim == null)
    {
        return String.Empty;
    }
    return emailClaim .Value;
}

and then call this method like this:

ClaimsPrincipal.Current.GetEmail()

Claims are following user in the cookie which is encrypted.

UPD: you should not store password in session because you should not need it after authentication. Once the user is validated and auth cookie is set, you should remove password from the memory. If you keep it in session after authentication, there are situation when session data is exposed one of the scenarios I can think of is exception stacktrace is dumped into ELMAH, and ELMAH exposes session variables in plain text. Another situation is when Glimpse is used - it shows session data.

As for social aspect of Identity - you can safely ignore all that and build your app only with internal list of users. I've just migrated one of my projects from MembershipProvider to Identity and did not take any dependencies on social auth.

As for VS2010 (why not upgrade?), Identity takes dependency only on Entity Framework 6.1, but does not depend on MVC or anything else, so there should be no problems with that, unless you are using Database First EF, in that case EF6.1 tooling might not work with VS2010. However, I have not tried this in VS2010 and I suggest you create a tiny test project in VS2010 that simulates Identity integration with your site.

Upvotes: 4

Related Questions