In this tutorial, you will learn how to make the Episerver context object work from the site visitors session state rather than values contained within a cookie. Using session state can be handy to give you more control over how users are authenticated on your site.
The reason why I wanted to do this was to lock a site visitors currency down, based on their location in the world. Whenever a website visitor signed up to the website and created an account, the address they entered defined their region and currency. The company did not want users to be able to change the currency, as this could potentially allow people to get items at a discounted rate. In a normal scenario, to get the current currency you would normally use the Episerver Commerce SiteContext instance and then get the value from the Currency property. The problem in this scenario is that the value is stored in a cookie. We had security concerns that a user might be able to cheat the system by changing the currency in their cookie. giving them access to better deals.
To accomplish this, I created a custom, project-based SiteContext that inherited from the Episerver SiteContext object. The custom site context was then registered within an initialisation module. This setting told Structure Map to use my custom context instead of using the default Episerver version. Intercepting the request this way allowed me to add all my custom code in a single location without impacting any other code. The Episerver APIs could carry on doing their thing oblivious to the fact that the mechanisms of how the data was being stored had changed. This ticked the good abstraction checkbox, perfect ✔️
In our situation, we had two ways the currency could be set.
Anonymous users: should be assigned the default currency based on their IP address. The
GeoLocationhelper can be used to figure this data out. Based on their current IP, a currency code will be returned. We could then pass that value into our custom currency repository which would return the default currency for that location.Logged In users: Should always use the currency stored against their user account. In our case, this data was stored in third-party customer service. When a known user logged in, the currency returned should be set based on this value
After we had the correct currency for either type of user, the value could then be stored in session state so the site didn't have to do the costly location/currency look-up again. This was done using MemoryCache stored against either the HttpContext.Current.Request We stored the value in a property called AnonymousID for anonymous users, or ProviderKey from the MembershipUser class for logged in users.
That was a lot of intro text, hopefully, you get the idea. it is time to look at some code 🔥🔥🔥
Memory Cacher Class: This code will allow you to add and remove items from the global cache.
The next part is creating the custom SiteContext object:
The last part of the puzzle is to configure StructureMap to inject this object, rather than use the default context:
That is all the cod you need 💥. Using these three things will allow you to define where the Commerce site context object reads and writes its values. We are now super secure. Happy Coding 🤘
