Session Storage and Class Storage

Question

I always saved data for the user (after logging in) in a session variable, so I can use this data on any page. I learned that another way to store information around the world is to store it in a class using { get; set;} { get; set;} , and then call it from any page.

Right now, I used both of these methods as a test, and they both work very well:

Session["LoginId"] = rdr["uniqueIdentifier"].ToString();

and

Member.LoginId = rdr["uniqueIdentifier"].ToString();

Where (In Member.cs )

 public class Member { public static int Challenges { get; set; } public static int NicknameId { get; set; } public static string LoginId { get; set; } public static string FriendsListId { get; set; } public static void ClearVariables() { Challenges = 0; NicknameId = 0; LoginId = null; FriendsListId = null; } } 

Global.asax

 void Session_End(object sender, EventArgs e) { Member.ClearVariables(); } 

My question is: is it safe to store user data in a class like this, or should I stick to Session objects?

Updated for completeness. Will this post do something like the above, but for multiple users? How to access session variables from any class in ASP.NET?

Answer 1

I found that this approach is one of the easiest to use and with the least chance of error. I think this is called a facade design pattern.

  public class SiteSession { #region Attributes private static string _siteSession = "__SiteSession__"; #endregion #region Constructor private SiteSession() { } #endregion #region CurrentSession public static SiteSession Current { get { SiteSession session = HttpContext.Current.Session[_siteSession ] as SiteSession; if (session == null) { session = new SiteSession(); HttpContext.Current.Session[_siteSession ] = session; } return session; } } #endregion #region SessionProperties public sherserve.CustomTypes.UserTypes UserType { get; set; } public int UserID { get; set; } public String StaffID { get; set; } public String Position { get; set; } public String StaffName { get; set; } public int TimeZone { get; set; } public String DealerId { get; set; } public String DealerPosition { get; set; } public String DealerName { get; set; } public int DealerFirmId { get; set; } public String ClientId { get; set; } public String ClientName { get; set; } public String ClientBusiness { get; set; } public String CountryCode { get; set; } public int ClientFirmId { get; set; } #endregion } 

Values ​​can be stored in a session as follows:

  SiteSession.Current.UserType = user.UserType; 

And you can get the following:

 int userId= SiteSession.Current.UserID; 

It is also a safe type.

Answer 2

In your case, this is not safe, since static variables in asp.net are common to all users.

Answer 3

Using static variables is not safe. The values ​​set for one user will overwrite the values ​​for another user.
A static variable will mean that only one variable is created and used for all sessions. The lifetime of static variables is the lifetime of the application.
If your variables are for user-defined (which seems to be), you will need to stick with session variables.

Answer 4

I am sure that it does not work for you. A class instance exists only as long as the request is processed. Once the request has been processed, you will not be able to get an instance of the class again. In the case of static variables, this application is wide and not suitable for storing user information.

The session is designed to process the state of the application by mail, and this is the only purpose of the session, i.e. Maintain the state of the application and is ideal for your requirement.

Answer 5

The disadvantage of the second approach is that when the application restarts the variable, it loses its values. But with the session, your data will be stored in browser cookies.

EDIT:

use only static variables if you need a common level of common (between all users) level at the application level.

Answer 6

Sessions are created for each user, and classes during the production process are created throughout the life of the application.

Despite the fact that you may not have problems developing with only one user, in each case, each request will override the previous data and, therefore, may pose a security risk.

Stick to sessions.