ASP.Net MVC Store User Entity In Session
First, don't store security-sensitive information in Session
. Google "ASP.NET Session hijacking" for info as to why.
That said, this code can be made to work. You just have a cast error. Also, You're not accounting for the fact that Session
can and does expire during a login. You could do this:
public static User CurrentUser
{
get
{
object userID = HttpContext.Current.Session["currentUserID"];
if (userID == null)
{
throw new InvalidOperationException("Oops!");
}
return Data.DBEntities.Users.Where(u => u.userID == (int)userId ).FirstOrDefault();
}
}
...which at least compiles, but isn't secure and sometimes throws.
It would be better to store the user ID on a custom principal, which is secure and doesn't expire.
Related videos on Youtube
tcode
Updated on June 04, 2022Comments
-
tcode over 1 year
I am developing an ASP.Net MVC 3 Web application with Entity Framework 4. When a user logs into my application I would like to store their user entity (firstName, lastName etc) in a session which can then be access throughout the application.
I understand that this may not be a good idea because when the ObjectContext closes/ disposes, then the User entity is detached and the user details could be lost.
I thought another method could be, when the user logs in, assign the userID (Primary Key) to a session variable, ie:
HttpContext.Current.Session["currentUserID"] = user.userID;
Then create a class in the UserService class like so:
public static User CurrentUser { get { return Data.DBEntities.Users.Where(u => u.userID == HttpContext.Current.Session["currentUserID"]).FirstOrDefault(); } }
Which should return a User Entity based on the currentUserID session variable. This isn't working for me however, I am getting a couple of errors
Cannot convert lambda expression to type 'string' because it is not a delegate type Delegate 'System.Func<Asset.Model.User,int,bool>' does not take 1 arguments
Is this approach I am taking correct, or is there a better way?
Any feedback would be much appreciated.
-
Kevin Gauthier over 12 yearsAside from the two problems already mentioned in my answer, this introduces the additional risk that your app might fail at runtime if you (1) switch to a distributed session store and (2) have any non-serializable properties. That said, I think "insecure and unreliable" are reasons enough not to put this in
Session
even without the additional risk.Session
is a user-specific cache, not a general-purpose, secure data store.