Storing data in AppState and Session - asp.net

In my AppStart.cshtml I fetch some data from the database, do calculations, serialize/deserialize json strings and such, etc, and I store the result in a couple AppState-variables by doing something like the following:(C#)
AppState["myVar1"]="aString";
AppState["myVar2"]=anArray;
These variables are accessed frequently and are a bit heavy to define so I thought something like this would make sense rather than creating the data from scratch every time it's needed. Even if the optimization isn't needed it still makes sense to me since it also increases readability and definitely maintainability by not having the same code in a bunch of places where that data is needed.
Likewise, I do similar actions on a per-user basis by putting data in Session whenver a user logs in, e.g.
Session["userVar1"]="myString";
Session["userVar2"]=myAray;
However, I've just read that we should never rely on that the data stored in these still exist when we want to read them because they're stored in the server-memory which might have been cleared.
Is this true?
So when we want to access one of these we should first check whether it's null or not? And if we're lucky it's not null and we can use it straight away, otherwise we set it again.
Is this how data stored in AppState and Session are supposed to be used? And if so, what would be a good way of re-setting them if they're null? I suppose doing something like creating a function which sets them if they're null?

In your case it sounds like it's fine if the data is occasionally cleared by the server (re-starting the app process from IIS, for example) because what you've described is just a caching scenario. Cache data is inherently transient. If it's there, use it. If it's not there, re-fetch it (and populate the cache again with the result).
What I would suggest is abstracting your cache mechanism (app state and session state) from the structure of the cache itself. And within this structure you can check if the data is cached and, if not, re-cache it. Consider an object like this:
public class CacheManager
{
public static string MyString
{
get
{
if (string.IsNullOrWhiteSpace(AppState["myVar1"]))
{
// Fetch the value to be cached and set it in AppState["myVar1"]
}
return AppState["myVar1"];
}
}
}
Now anywhere in your application you can get the value by calling:
CacheManager.MyString
The rest of the application doesn't know or care if it's from app state, or session state, or a database, or a file, or any other transient location for cached data. That's entirely handled by the cache manager object. So if you ever want to change where certain values are located, you change them in that one place. Or if, for testing purposes, you want to remove the cache entirely and always get the data live, you'd just swap out the cache manager implementation with one that always returns re-fetched data. The rest of the application is blissfully unaware of the implementation.

Related

Storing Temp. Data in ASP.NET Core (NopCommerce)

Dear StackOverflow community,
For a project of mine I need to store (Temporary) data somewhere else than a Database. Actually its a little more complicated. I have a checkout page in NopCommerce where users can select them delivery moment or even location for example pickup. This data has to be store temporary untill the user made the payment. Only then I will request the data and store in DB. So that later I can retrieve the data and display in my dashboard, So that I know when the package is scheduled to be shipped.
Requirements:
Endurement: 12-24 Hours.
Store as user specific data.
Data has to be safed for quite a few sessions. Depends on the user. For example. If the user chooses a delivery moment but desides to look somewhere else before paying. This data has to be stored all those sessions.
If possible serverside.
I have quite a few options following Microsoft:
Session and state management in ASP.NET Core
Now I have tried storing data in Memory (Caching data) using 'MemoryCacheEntryOptions'. The problem is that its application wide. And its hard to maintain with hundreds of users.
Other option is 'Session state'.
The problem is that this data only endures a single session. I need to hold the data for atleast 12 to 24 hours.
Then we have 'Temp Data'. This seems like a promising option. Its great since it is kept until the is has been used/read. You even have 'Peek' and 'Keep' Methods to keep the data while peeking. Problem: It requires a controller. And requesting the data is a callback Method that doesnt require a Controller.
'Query Strings' Well its not much is it? This may be not user critical data BUT seems like query string isnt what Im looking for.
'Hidden Fields' Not really suitable either. It is therefore not form data.
'HttpContext.Items' Definetly not suitable. Data is only stored for single request.
'Cache' Way to hard to maintain user specific data.
So my question is. How do I save all this data temporary, if possible server side for a day atleast with hundreds of users at the same moment. And request the data later in a callback, to store it in DB until the order is shipped.
NopCommerce exposes a class called GenericAttributeService in Nop.Services.Common. This allows you to store your custom attribute data, specific to each customer.
To use it, first inject the GenericAttributeService into your class (controller, service class, etc).
private readonly IGenericAttributeService _genericAttributeService;
public MyFancyController(IGenericAttributeService genericAttributeService)
{
_genericAttributeService = genericAttributeService;
}
To save the data for current customer, use SaveAttribute and save an key-value pair you need:
_genericAttributeService.SaveAttribute<string>(_workContext.CurrentCustomer, "MyKeyName", "Value to save for this customer")
_genericAttributeService.SaveAttribute<int>(_workContext.CurrentCustomer, "My2ndKeyName", model.id)
To get the data use GetAttributesForEntity, where the entity is your key value.
var attribute = _genericAttributeService.GetAttributesForEntity(_workContext.CurrentCustomer.Id, "Customer").Where(x => x.Key == "MyKeyName").FirstOrDefault();
To delete the attribute use DeleteAttribute:
_genericAttributeService.DeleteAttribute(attribute);
Notice that we used _workContext which helps expose the current customer.
This already works well with other temp functionality already existing in the application, such as managing shopping carts, wish lists, etc, so browsing the source code for other examples can also be helpful.

TempData implementation changes - Reasons for the change

In ASP.NET MVC 2, the lifespan of an entry in the TempDataDictionary was just one HTTP Request.
That translated to setting a value in one request, redirecting, and having access to the same item at the other end of the line. After this the entry would be no longer available, regardless of whether you read the value out of the dictionary at the latter end of the line or not.
Since ASP.NET MVC 3 (I believe), this implementation detail has changed quite significantly.
Entries in the TempDataDictionary are now only removed once they've been read.
MVC 4
public object this[string key]
{
get
{
object obj;
if (!this.TryGetValue(key, out obj))
return (object) null;
this._initialKeys.Remove(key);
return obj;
}
}
and
public bool TryGetValue(string key, out object value)
{
this._initialKeys.Remove(key);
return this._data.TryGetValue(key, out value);
}
MVC 2:
public object this[string key] {
get {
object value;
if (TryGetValue(key, out value)) {
return value;
}
return null;
}
and
public bool TryGetValue(string key, out object value) {
return _data.TryGetValue(key, out value);
}
Since most people seem to put items in the TempData collection in one request and immediately read them back out in the immediate next request, the functionality seems roughtly the same.
In scenarios where this is not the case such as wanting to read the TempData entry if redirected to one place, and expecting it to have been removed if requesting other resources and navigating back, this change has quite an impact.
No longer is the entry available for one http request but is available over many HTTP requests, be it only available to one single get on the dictionary.
I'd like to know more about this implimentation change, what were the reasons for the change, was this simply to cater for multiple redirects or are there deeper benefits?
Secondary to that, I'm intrigued to know if there's anything built in that now caters for single HTTP request sharing of data in the same way that TempData used to cater for?
You're correct that TempData keys are only cleared if they’ve been read (or after the user’s session expires) but this has been the case since MVC2, (http://forums.asp.net/post/3692286.aspx)
I'd like to know more about this implimentation change, what were the
reasons for the change, was this simply to cater for multiple
redirects or are there deeper benefits?
This change prevented problems that arose in MVC 1, such as TempData keys being deleted before they were read. So yes, the primary benefit is in avoiding these problems when you have multiple re-directs, or interleaved requests. In addition, the RedirectToRouteResult or RedirectResult methods now automatically call TempData.Keep() to prevent clearing of keys, even after they've been read so keep that in mind as well.
In scenarios where this is not the case such as wanting to read the
TempData entry if redirected to one place, and expecting it to have
been removed if requesting other resources and navigating back, this
change has quite an impact.
You’re correct, if you've been coding under the assumption that the TempData keys are cleared automatically you could run into unexpected problems. You can call TempData.Clear() to manually remove all keys from the TempDataDictionary, or TempData.Remove(key) to remove a specific key. You can also use TempData.Peek() to read the value of a TempData key without flagging it for removal from the TempDataDictionary.
Secondary to that, I'm intrigued to know if there's anything built in
that now caters for single HTTP request sharing of data in the same
way that TempData used to cater for?
I'm not aware of any new objects or functions that replicate the original implementation of TempData. Essentially we still use TempData but have to be mindful that the data persists until read and clear the dictionary manually if needed.

Security Issue with ASP.NET and SQL Server

A problem appears when two users are logged on to our service system at the same time and looking at the service list gridview. If user1 does a search to filter the gridview and user2 happens to click to another page user2 sees the results from the search performed by user1. That means one company can see another company's data.
It's an ASP.NET application that was developed in house with C#/ASP.NET 3.5. The data is stored in a SQL 2000 database and relies very heavily on stored procedures to update, select, and delete data. There are multiple user types that are restricted to what data they can see. For example, we have a company use that can only see data relavant to that company.
From what I've seen, the security is handled through If statements in the front end. Example, if userlevel = 1 then do this, if userlevel = 2 do this. These statments are used to show or hide columns in a grid, run queries to return data, and any other restrictions needed. For a company user the code behind gets the companyid assigned to the user and uses that in a query to return the results of all the data associated with that companyid (services, ships, etc).
Any recommendations for fixing this will be highly appreciated.
It's hard to say without seeing any implementation details, but on the surface it appears that there maybe some company level caching. Check for OutputCache settings, DataSource caching, explicit caching with Page.Cache, etc.
This article is a little dated, but at a glance it looks like most information is still relevant in ASP.NET 4.0.
ASP.NET Caching: Techniques and Best Practices
In addition to jrummerll's answer, check the Data Acces Layer of our app and make sure that you don't have any static variables defined. Having a static variable defined could cause this sort of issue too, since 2 contending requests may overwrite the value of the CompanyID, for example.
You basic model should work. What you've told us is not enough to diagnose the problem. But, I've got a few guesses. Most likely your code is confusing UserID or CompanyID values.
Are you mistakenly storing the CompanyID in the Cache, rather than the session?
Is the CompanyID stored in a static variable? A common (and disastrous!) pitfall in web applications is that a value stored in a static variable will remain the same for all users! In general, don't use static variables in asp.net apps.
Maybe your db caching or output caching doesn't vary properly by session or other variables. So, a 2nd user will see what was created for the previous user. Stop any caching that's happening and see if that fixes it, but debug from there.
Other variations on the above themes: maybe the query is stored in a static variable. Maybe these user-related values are stored in the cache or db, but the key for that record (UserID?) is stored in a static variable?
You can put that if statements in a thread. Threading provides you the option that only 1 user can access the application or gridview in your case.
See this link: http://msdn.microsoft.com/en-us/library/ms173179.aspx
Here is some sample code that is throughout the entire application that is used for filtering results. What is the best way to fix this so that when one user logs on, the other user doesn't see those results?
protected void PopulategvServiceRequestListing(string _whereclause)
{
_dsGlobalDatasource = new TelemarServiceRequestListing().GetServiceRequestListingDatasource(_whereclause);
if(_dsGlobalDatasource.Tables[0].Rows.Count!=0)
{
gv_ServiceRequest.DataSource = _dsGlobalDatasource;
gv_ServiceRequest.DataBind();
}
else
{
gv_ServiceRequest.DataSource=new TelemarServiceRequestListing().DummyDataset();
gv_ServiceRequest.DataBind();
gv_ServiceRequest.Rows[0].Visible = false;
gv_ServiceRequest.HeaderStyle.Font.Bold = true;
}
}

Cache user control

The problem of ouputcaching is avoiding accessing the object, it is cached and it will not be processed at ALL and it is a HTML. for example, what if I want to post back to initialize countries drop down list with specific selection, I don't want to go back and rebuild the whole control and rebind to a collection of countries to just intialize the contol to a certain country.
Output caching will not solve the problem because it caches the HTML, not the object, the object will be null, I can't manipulate it.
Is there away to cache the server object rather than caching its output html?
If u don't think this is possible please reply back, so I know that it is impossible if alot of people say so.
Thanks
It's quite possible - just use the HttpRuntime cache:
HttpRuntime.Cache.Add("myKey", myCountryList);
And then fetch the object back out:
CountryList myCountryList = HttpRuntime.Cache["myKey"] as CountryList;
if(myCountryList == null)
{
//the object isn't in cache
}
This is the most simple usage - the cache is fairly robust and supports some more complex behaviors like invalidation, callbacks, etc. which is all covered in the link above.

Static data in an ASP.NET page - threadsafe?

The background to this question is that I need to use some user session data in a (static) WebMethod. I have created a static property that references the data I need like so:
private static UserWebSession UserWebSession
{
get
{
return (UserWebSession)HttpContext.Current.Session["UserWebSession"];
}
}
I can then call this in my page's static WebMethod.
My question is, is this technique thread safe? Or will this property's value be updated with every new page request - in other words, it will return the UserWebSession for the user who most recently requested the page?
That's fine - HttpContext.Current is designed precisely for this sort of thing. You won't get a previous user's session.
It's dependent on the thread though (I believe) - so if you start any extra background threads, they won't be able to see the current context.
Also be aware that although this call is safe in terms of not getting the wrong context, the normal concurrency caveats apply when it comes to what you actually do with the context.
I don't know that a Page Method is able to access Session state. If it can, then you may be ok. I recall that access to Session state is serialized, so that only one request at a time can arrive for a given session.

Resources