X-FRAME-OPTIONS is a web header that can be used to allow or deny a page to be iframed. This is very important when protecting against clickjacking attempts. Using this header you can ensure that your content is not rendered when placed inside an IFrame, or only rendered under certain conditions (Like when you are framing yourself).

A common alternative to protect against clickjacking is to use javascript code to “break” iframes when your website is placed in them. This works for the most part but will obviously fail if the user does not have JS enabled, or (more common than you think), you forget to load the JS file on a particular page.

X-Frame-Options Settings

Your options when setting the header as as follows.

X-FRAME-OPTIONS : DENY
The page cannot be put in a frame no matter who it is (Including the site framing itself). If you don’t use frames on your own site then this is a good catch all.

X-FRAME-OPTIONS : SAMEORIGIN
The page can be framed as long as the domain framing it is the same. This is good if you are using frames yourself.

X-FRAME-OPTIONS : ALLOW-FROM https://myotherdomain.com
The page can be framed by the specified domains. Good if you have two sites with one framing the other.

Note that Allow-From is only supported in Firefox and IE. Chrome and Safari have both said that they will not support it and instead implement “Content-Security-Policy”, an alternative way to prevent clickjacking (And the subject of a future post!). Because of that it is not recommended you use this setting, stick with DENY or SAMEORIGIN.

Setting X-Frame-Options At The Code Level

Adding X-FRAME-OPTIONS to your .NET Core app is very simple. In your Configure method in your startup.cs, you need to add a custom middleware like so :

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
	app.Use(async (context, next) =>
	{
		context.Response.Headers.Add("X-Frame-Options", "SAMEORIGIN");
		await next();
	});

	app.UseMvc();
}

And that’s all! Now every request that runs through your ASP.NET Core app will be protected.

Setting X-Frame-Options At The Server Level

You (or your dev ops team) may prefer to configure headers at the server level. In that case below are the various ways to add X-FRAME-OPTIONS to your web server so every request gains the header.

Setting X-FRAME-OPTIONS in IIS

The best way to do this if you are just using IIS to forward requests to Kestrel (Or even if this is actually being hosted in IIS), is to do this in IIS Manager.

1. Open IIS Manager and on the left hand tree, left click the site you would like to manage.
2. Doubleclick the “HTTP Response Headers” icon.
3. Right click the header list and select “Add”
4. For the “name” write “X-FRAME-OPTIONS” and for the value write in your desired option e.g. “SAME-ORIGIN”.

Setting X-FRAME-OPTIONS in Apache

In your httpd.conf file you need to append the following line :

Header always append X-Frame-Options SAMEORIGIN

Setting X-FRAME-OPTIONS in htaccess

If you are using shared hosting you may only have access to an HTAccess file. Or you may prefer to use HTAccess to manage redirects, headers etc anyway. If that’s the case you need to add the following to your .htaccess file.

Header append X-FRAME-OPTIONS "SAMEORIGIN"

Setting X-FRAME-OPTIONS in NGINX

In nginix.conf add the following line (And restart the nginx service afterwards).

add_header X-Frame-Options "SAMEORIGIN";

Redis is a high performance distributed cache. It’s great for storing data that you are going to need again and again in a short period of time when you don’t want to use processing power to “create” that data again. Think number crunching or heavy SQL queries for data that doesn’t change often.

Roll Your Own

First off. You can absolutely roll your own Redis Cache services abstracted by your own interfaces etc. You may find it a little difficult to find libraries that target .NET Core, but this will change over time.

In saying that, there is a “.NET core” way of doing things that is a little different. It does tie you into the framework a little, but it abstracts away the caching completely and let’s Microsoft handle it and that’s what we are going to go over today.

The ASP.NET Core Way

The first thing you need to do is add the Redis caching package provided by Microsoft. You can do this in your package manager console by running :

Install-Package Microsoft.Extensions.Caching.Redis

In your startup.cs, you now need to add the following to your ConfigureServices method. It should look something like :

public void ConfigureServices(IServiceCollection services)
{
	services.AddMvc();

	services.AddDistributedRedisCache(option =>
	{
		option.Configuration = "127.0.0.1";
		option.InstanceName = "master";
	});
}

For your Configuration, while I’ve hardcoded this to 127.0.0.1, you can obviously change this to pull from your configuration as required. Either from AppSettings/ConnectionStrings etc.

And as you can probably guess with the method signature of “AddDistributedRedisCache”, you can also use things like SQL or InMemory caches using a similar sort of method. We will go over this in future posts!

AddDistributedRedisCache actually adds an interface automagically to your service collection called “IDistributedCache” that you can then use to set and retrieve values. You can then use controller dependency injection to get this anywhere in your app. So say we have a controller called HomeController and it wants to use the RedisCache. It would go :

[Route("api/[controller]")]
public class HomeController : Controller
{
	private readonly IDistributedCache _distributedCache;

	public HomeController(IDistributedCache distributedCache)
	{
		_distributedCache = distributedCache;
	}

	[HttpGet]
	public async Task<string> Get()
	{
		var cacheKey = "TheTime";
		var existingTime = _distributedCache.GetString(cacheKey);
		if (!string.IsNullOrEmpty(existingTime))
		{
			return "Fetched from cache : " + existingTime;
		}
		else
		{
			existingTime = DateTime.UtcNow.ToString();
			_distributedCache.SetString(cacheKey, existingTime);
			return "Added to cache : " + existingTime;
		}
	}
}

The first time we view this page, there is nothing in the cache so we are given a new time. And it’s added to the cache. If we refresh the page, we then end up with the time that was cached. So for example :

Added to cache : 5/01/2017 1:27:24 AM
*refresh page a few seconds later*
Fetched from cache : 5/01/2017 1:27:24 AM

A couple more notes.

• IDistributedCache has async methods. You should use these in all scenarios that are possible.
• IDistributedCache allows for storing either string values or byte values. If you want to serialize an object and store the entire thing, you can either serialize it to bytes and save it as bytes, or serialize it to JSON and save it as a string if you prefer.
• As discussed earlier, while this is a Redis distributed cache, there are other implementations available that follow the exact pattern for InMemory, SQL Server etc.

If you need to use an InMemory Cache rather than Redis, see our tutorial on In Memory Caching here

HttpContext has had a bit of a shifting around in ASP.NET Core. While everyone has their own ideas on best practices, it’s a bit of a consensus that the usage of calling “HttpContext.Current” outside the scope of a controller (For example in a service class) was getting out of hand. It also made testing just that little bit harder.

So how to do it now? There are two ways.

Inside Controllers

Inside a controller, you can still access HttpContext by doing the following :

[HttpGet]
public async Task<bool> LoggedIn()
{
	var myUser = HttpContext.User;
	return myUser.Identities.Any(x => x.IsAuthenticated);
}

No, there is nothing special that I have done to access the Property “HttpContext”, it’s just available when inheriting from the base “Controller” class. Simple!

Inside Services

Inside services is a little tricker, but still possible. Note that you may want further abstraction away from directly accessing an HTTPContext, for example if you are using it for “Sessions” you may want to abstract it away incase you scale your servers horizontally and you will no longer be able to use the HTTP Session object within C#. But if you don’t think you’ll need that, read on!

First in your startup.cs, you need to register IHttpContextAccessor as a service like so :

public void ConfigureServices(IServiceCollection services)
{
	services.AddMvc();
	services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
}

In earlier versions of .NET Core, IHttpContextAccessor was automatically registered. This was removed and announced here. So you need to register it manually if you intend to use this inside services.

When you create a helper/service class, you can then inject in the IHttpContextAccessor and use it. It would look like something not too dissimilar to this :

public class UserService : IUserService
{
	private readonly IHttpContextAccessor _httpContextAccessor;

	public UserService(IHttpContextAccessor httpContextAccessor)
	{
		_httpContextAccessor = httpContextAccessor;
	}

	public bool IsUserLoggedIn()
	{
		var context = _httpContextAccessor.HttpContext;
		return context.User.Identities.Any(x => x.IsAuthenticated);
	}
}

Unfortunately if you have accessed HttpContext throughout your old .net 4.5 code and are looking to upgrade to .net Core, you will have to do a bit of work to get it working again. But it’s worth it for the nice clean approach to DI and better testability.

By default, browsers abide by the Same-Origin policy, which is that documents (Or in most cases scripts) cannot interact with a resource from another domain. It isolates, for example, a malicious script being able to do “too much”. A script loaded from a third party should not be able to call your own API. However in some cases this actually may be warranted.

Enter CORS

CORS or Cross-Origin Resource Sharing is a way to by-pass this limitation/security measure for legitimate reasons. The most common in the context of ASP.NET core is that you are building a Single Page Application, and you wish to host your API on another domain. For example your website is www.mywebsite.com and your API is api.mywebsite.com. Any scripts be they from jQuery, Angular, React, Backbone, whatever cannot make HTTP calls from www.mywebsite.com to api.mywebsite.com.

Configuring CORS In ASP.NET Core

Let’s get going and see how this works in ASP.NET Core

First you need to add the Microsoft Cors package from Nuget.

Install-Package Microsoft.AspNetCore.Cors

You then need to add the CORS services. In your startup.cs in your ConfigureServices method you should have something similar to the following :

public void ConfigureServices(IServiceCollection services)
{
    services.AddCors();
}

Next you need to add the CORS middleware to your app. In your startup.cs you should have a Configure method. You need to have it similar to this :

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
	app.UseCors( options => options.WithOrigins("http://www.mydomain.com").AllowAnyMethod() );

	app.UseMvc();
}

The options lambda is a fluent API so you can add/remove any extras you need. You can actually use the option “AllowAnyOrigin” to accept any domain, but I highly recommend you do not do this as it opens up cross origin calls from anyone. You can also limit cross origin calls to their HTTP Method (GET/PUT/POST etc) so you can only expose GET calls cross domain etc.

Important!

Two very important points.

• Incase it wasn’t obvious, the above is to be done on your API not your web project!
• Your protocol is important. http://www.mydomain.com is not the same as https://www.mydomain.com

In a previous article we went over how to read custom configurations into memory in ASP.NET Core. This is also the new way to do Appsettings. But did you know that you can also do “hot loading” of configurations? That is, while your app is running, you can change an appsetting or configuration and your application will reload it on the fly without an app pool recycle or restarting the web server? Pretty nifty! Let’s take a look.

A couple of notes before we start :

• We will be reusing our code from the custom configurations in ASP.NET Core tutorial. If you haven’t read that yet maybe take a quick read to make sure we are on the same page.
• This only works in ASP.net core 1.1 and up. Before that there were a couple of hot loading options that made it into early versions but ended up being problematic and being removed. In earlier versions this was named IOptionsMonitor (Which is still there under the hood).

First, in your Startup.cs ensure that when you load your appSettings.json, that reloadOnChange is set to true. It should look something like this :

var builder = new ConfigurationBuilder()
	.SetBasePath(env.ContentRootPath)
	.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true);

When you load your configuration into your services collection, you now must load it as configuration as opposed to loading it as a POCO. That means it should look like this :

services.Configure<MyConfiguration>(Configuration.GetSection("myConfiguration"));

When you request it into your controller/service, you then need to use IOptionsSnapshot rather than IOptions.

private readonly MyConfiguration _myConfiguration;

public MyController(IOptionsSnapshot<MyConfiguration> myConfiguration)
{
	_myConfiguration = myConfiguration.Value;
}

And that’s all! Now whenever you change configuration, your configuration is reloaded and your changes are seen instantly without a large restart required. This would be handy if you were deploying a prototype or a new feature that you’re unsure of how it would perform and need a way to tune it or disable the feature all together without requiring wholesale restarts.

Important. It’s A Snapshot!

It should be noted that the name IOptionsSnapshot is as the name implies, it’s a snapshot. If you for example take the value and hold onto that for some reason (In your own cache for example), these will not be hot loaded when changing configuration. Instead each time IOptionsSnapshot is injected into a class it will be given it’s unique value. This is very important to remember. Consider the following code :

private readonly IOptionsSnapshot<MyConfiguration> _myConfiguration;

public MyController(IOptionsSnapshot<MyConfiguration> myConfiguration)
{
	_myConfiguration = myConfiguration;
}

[HttpGet("")]
public bool Get()
{
	var first = _myConfiguration.Value.MyProperty;
	var second = _myConfiguration.Value.MyProperty;
	return second;
}

Where the configuration value of MyProperty is a boolean. If between the first and second calls to the value of MyProperty, I go into the configuration and change the value. What do you think this action will return? The answer is true as IOptionsSnapshot only reads the configuration when being created, not when you request the value from it.

In our example here, we are using an MVC controller which is Transient scope. Meaning that each time we request the controller, our DI recreates it for us. But it’s important to remember that if you are using something with a Singleton scope (Or to some extent a “scoped” scope), and injecting IOptionsSnapshot into that, the options will never be updated.

Frustratingly .net Core early releases were without URL Encode and Decode methods. Whereas previously you were able to access the HTTPUtility namespace for encoding and decoding strings, this was not ported to .net core.

Until now!

Microsoft has moved the UrlEncode and Decode methods into a WebUtility static class. If you are super nosy you can see the code that’s doing your encoding here.

To get access you need to install this nuget package, which at the time of writing means running this command from your package command line :

Install-Package Microsoft.AspNet.WebUtilities -Pre

Now you have access to URL Encoding

var myEncodedString = System.Net.WebUtility.UrlEncode("my string");

Custom Model Binders are a super helpful tool in “binding” a view model in unconventinal ways. There are a few reasons you may find yourself using a custom model binder.

1. You are taking in values in seperated out fields, but want to combine them into a single object/struct.
2. The model the front end is sending is actually nothing like the backend model, and neither side can change for some reason. (We’ve all been there!)
3. You need to “Supplement” your model with outside data that isn’t coming in the payload (e.g. a cookie, a value from a database/config etc).

We will be focussing on the first reason as it’s the easiest to demonstrate. However once you have the hang of a custom model binder the possibilities really open up and there is no limit to what you can bind.

In our example, we are requesting a URL like the following :

http://www.mydomain.com/date?day=1&month=2&year=1985

This might happen if you have separated out select boxes for your dates for whatever reason. You end up with each portion of the date coming through individually. On the backend this can be a pain because we want to deal with a single Datetime object. We could receive all of these individually and build them up in the action, or we could “bind” them before it even reaches the action. Let’s see how.

First, we build our ViewModel of what we want to receive. In our case it’s a simple class with a single property :

public class MyViewModel
{
	public DateTime MyDate { get; set; }
}

Next we build a “ModelBinder” that inherits from IModelBinder. This might look like the following :

public class MyViewModelBinder : IModelBinder
{
	public Task BindModelAsync(ModelBindingContext bindingContext)
	{
		var day = 0; 
		var month = 0; 
		var year = 0;

		if(!int.TryParse(bindingContext.ActionContext.HttpContext.Request.Query["day"], out day) || 
		!int.TryParse(bindingContext.ActionContext.HttpContext.Request.Query["month"], out month) || 
		!int.TryParse(bindingContext.ActionContext.HttpContext.Request.Query["year"], out year))
		{
			return Task.CompletedTask;
		}

		var result = new MyViewModel
		{
			MyDate = new DateTime(year, month, day)
		};

		bindingContext.Result = ModelBindingResult.Success(result);
		return Task.CompletedTask;
	}
}

Notice that in this case we reach into the query string to read our values, but this could be from anywhere.

In the latest version of ASP.NET core, we also need to use a provider. A provider tells ASP.NET core when to use our custom binder. For us it’s very simple. If the model we are binding to is of type “MyViewModel” then use our binder. Of course this can be much more complicated and can even return different binders based on code within the provider. Our provider looks like the following :

public class MyViewModelBinderProvider : IModelBinderProvider
{
	public IModelBinder GetBinder(ModelBinderProviderContext context)
	{
		if (context.Metadata.ModelType == typeof(MyViewModel))
			return new MyViewModelBinder();

		return null;
	}
}

Simple!

Next we just need to let ASP.NET Core know that we have a model binder ready for use. You do this in your startup.cs file in the ConfigureServices method. Note that we “insert” our model binder provider at the start of the list. This is because it’s first in first served, so we want to make sure that our modelbinder is always the first to run if possible.

public void ConfigureServices(IServiceCollection services)
{
	// Add framework services.
	services.AddMvc(config =>
		config.ModelBinderProviders.Insert(0, new MyViewModelBinderProvider())
	);
}

Finally, create your action in your controller that asks for “MyViewModel”. Something like the following :

[HttpGet("")]
public string Get(MyViewModel viewModel)
{
	if (viewModel == null)
		return "Woops. We received null!";
	return $"The date you sent was {viewModel.MyDate}";
}

And all going well, when you call your URL you should see :

The date you sent was 1/02/1985 12:00:00 AM

As you can see, Model Binding really isn’t that hard. It may seem a bit overkill at first, but simply knowing it exists means that when that one time you actually need it comes up, you have it ready to use at your disposal.

If you’ve been using ASP.NET for any length of time you’ve probably had to build your own implementation of the CustomConfiguration class or had to implement the IConfigurationSectionHandler. This usually included writing out each configuration element and how to read it from the XML (Including conversions/casts). What a pain!

DotNetCore takes a much simpler approach to custom configurations. There are two main ways to use it, one that uses an Options class from .net Core, and one that uses simple POCOs.

Method 1 : The Options Class

This way is the most common example you’ll see out there. It uses the Options class built into .net core and is pretty easy to get going. Because it drags around the “options” class, it actually isn’t my preferred method. I much prefer simple POCO’s. If you do too, then skip to Option 2 below. Otherwise read on!

Imagine you have an appSettings.json like so :

{
  "myConfiguration": {
    "myProperty": true 
  }
}

You would create a simple configuration class like the following in your project :

public class MyConfiguration
{
    public bool MyProperty { get; set; }
}

Notice how in the above we don’t have to inherit or implement any interfaces/classes. It’s a simple POCO that doesn’t require any additional references.

Now in your startup.cs, you have the following :

public class Startup
{
	public Startup(IHostingEnvironment env)
	{
		var builder = new ConfigurationBuilder()
			.SetBasePath(env.ContentRootPath)
			.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
			.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
			.AddEnvironmentVariables();
		Configuration = builder.Build();
	}

	public IConfigurationRoot Configuration { get; }

	public void ConfigureServices(IServiceCollection services)
	{
		services.Configure<MyConfiguration>(Configuration.GetSection("myConfiguration"));
	}
}

Notice in the ConfigureServices method we add a configuration to our services. This is all it takes

Next we go to any controller and we can reference IOptions<MyConfiguration> to access our custom configuration.

public class ValuesController : Controller
{
	private readonly MyConfiguration _myConfiguration;

	public ValuesController(IOptions<MyConfiguration> myConfiguration)
	{
		_myConfiguration = myConfiguration.Value;
	}
}

Simple right? But from the above you can probably pick why this isn’t my preferred method. We drag along this IOptions interface but pull the value from it immediately. If we could inject our POCO class that holds our configuration then we don’t need to drag around the IOptions interface. Let’s take a look at that.

Method 2 : Get Configuration Poco

Utilizing what we already have above, we just need to change a couple of lines. In our startup.cs we need to change the call to configure to one that just binds a POCO :

public void ConfigureServices(IServiceCollection services)
{
	//services.Configure<MyConfiguration>(Configuration.GetSection("myConfiguration"));
	services.AddSingleton(Configuration.GetSection("myConfiguration").Get<MyConfiguration>());
}

A couple of notes :

• You previously were able to call “AddInstance” on an IServiceCollection. This was removed to just allow “AddSingleton”, which really is one and the same anyway.
• Previous versions of .net Core (Pre 1.1) did not allow a call to “Get”, instead you had to do a call to “bind”. This was an added annoyance as you had to instantiate an empty class first. If you are on an early version and unable to upgrade, do the below.

Bind option (Pre ASP.NET core 1.1) :

public void ConfigureServices(IServiceCollection services)
{
	//services.Configure<MyConfiguration>(Configuration.GetSection("myConfiguration"));
	MyConfiguration configuration = new MyConfiguration();
	Configuration.GetSection("myConfiguration").Bind(configuration);
	services.AddSingleton(configuration);
}

Then if you go to your class, you only need to ask for your POCO, not the IOptions. Like so :

public class ValuesController : Controller
{
	private readonly MyConfiguration _myConfiguration;

	public ValuesController(MyConfiguration myConfiguration)
	{
		_myConfiguration = myConfiguration;
	}
}

Best Practice

If you go with Method 2. A good habit to get into is to always inject in an interface instead of your concrete class. This allows for easier mocking when doing unit testing, and it better follows the Dependency Inversion principle which is that you depend on abstractions.