Hiding ProxyApi Routes from Web API Help Pages

If you are using ProxyApi and you have tried out the Web API Help Pages feature then you will have noticed a bunch of duplicate routes showing up for all of your actions that look something like this:

GET /api/{proxy}/Controller/Action?foo=bar

ProxyApi needs to be certain of the Route-to-Controller/Action mapping in order to correctly generate the JavaScript proxies, and it achieves this by inserting a custom route at the start of the route table so that it will always take precedence (if matched).

Unfortunately the Web API ApiExplorer finds these routes, maps them to the action and generates a duplicate route for every action in your API!

Getting Rid of the Routes

Thankfully it is very simple to filter these out.  When you add the Web API help pages package to your project it will generate a LOT of code that builds and renders the help page content.  This gives you plenty of entry points in which you can intercept and hide the ProxyApi-specific routes.

For our purposes here we can subclass the ApiExplorer class and filter out any route that contains “{proxy}”.

public class CustomApiExplorer : ApiExplorer
  public CustomApiExplorer(HttpConfiguration config) : base(config)

  public override bool ShouldExploreAction(string actionVariableValue, HttpActionDescriptor actionDescriptor, IHttpRoute route)
    if (route.RouteTemplate.ToLower().Contains("{proxy}"))
      return false;

    return base.ShouldExploreAction(actionVariableValue, actionDescriptor, route);

Now we just need to plug this implementation in instead of the default…

//in your help page configuration
config.Services.Replace(typeof(IApiExplorer), new CustomApiExplorer(config));

…and we’re done!


Excluding Current RouteData from UrlHelper

By default, the MVC UrlHelper will include all of the route values for the current route in it’s calculations.

This means that unless you explicitly override them you can get situations like this:

<!-- on page /Person/View/1 -->
<a href="@Url.Action("View", "Pet")">View Animal</a>
<!-- URL resolves to /Pet/View/1 -->

Disaster – the ID from the current request has been included in the new URL!

In some cases this can be very useful – this is the reason that you don’t need to specify a controller if you are already within a view on the same controller – but can be very annoying when you want to create a URL in isolation (see here and here).

Using the Isolate Extension

To get around this problem I have written an Isolate extension method that can be used as below:

<!-- on page /Person/View/1 -->
<a href="@Url.Isolate(u => u.Action("View", "Pet"))">View Animal</a>
<!-- URL resolves to /Pet/View -->

The extension works by temporarily removing all of the existing route values from the specified instance of UrlHelper, executing the action, and then re-inserting the original route values before returning the result.

public static TResult Isolate<TResult>(this UrlHelper urlHelper, Func<UrlHelper, TResult> action)
	var currentData = urlHelper.RequestContext.RouteData.Values.ToDictionary(kvp => kvp.Key);
		return action(urlHelper);
		foreach (var kvp in currentData)
			urlHelper.RequestContext.RouteData.Values.Add(kvp.Key, kvp.Value.Value)

It’s a basic solution and there are some (predictable) scenarios where it will fall down, but it solved my immediate problem without adding to much bloat to the code.

ProxyApi & Anti-Forgery Tokens

Anti-Forgery Tokens?

Good question.  Anti-forgery tokens are a recommended way of preventing one of the OWASP Top Ten security vulnerabilities: Cross Site Request Forgery, or CSRF.

CSRF works on the basis that once you have logged into YourSite using your browser, any request to that domain will share the authentication information.  Normally, requests to YourSite would come from YourSite, but other developers are perfectly capable of writing some code on their site that tries to make a request to YourSite to do something evil.

Though there are a few ways of preventing or reducing the risk of CSRF attacks, anti-forgery tokens are the currently recommended approach.

So how do they work?  Whenever the server serves up a page that may result in a submission (e.g. a page that contains a form) it sets a randomly-generated cookie value.  The client must then include the random value in both a hidden form field and the request cookie; otherwise, the server will reject the request as invalid.  Attackers will not be able to read the cookie value; therefore they cannot include it as a form field and so their attack fails.

ASP.NET MVC Implementation

MVC makes it very easy to implement anti-forgery tokens.  Very easy.

Step 1: add an attribute to your action or controller

public ActionResult DoSomething()

Step 2: include the following within the form on the page


Unfortunately WebAPI does not have a similar implementation, but there are thankfully a lot of examples out there (e.g. Kamranicus’ example & the MVC SPA template ) of how to achieve similar functionality that works with WebAPI.

So how can we adapt these ideas to work with ProxyApi?

ProxyApi Implementation

The intention of this library is to allow you to quickly create proxy classes for WebAPI methods; because it is expected to be running in the browser (it generates JavaScript, after all) it will be using cookie authentication and should therefore consider CSRF.

Ideally, the developer using the library doesn’t want to do anything more than they do for their MVC implementation, so it would seem like that is a good convention to follow.

Setting The Token

As with MVC, setting the cookie token and inserting the hidden form value onto the page is done by calling the Html.AntiForgeryToken() method in your view.  This is deliberately identical to the MVC method to keep things as consistent as possible.

Decorating the Controller

Following the same pattern as MVC and the examples listed above, the ProxyApi implementation uses an attribute that can be specified against a controller or an action:

public void PostSomething(Something data)

This attribute is an extension of AuthorizationFilterAttribute that uses the cookie- and hidden tokens to validate the request.  The second value – the one that would normally be included as a hidden form field – is instead expected as a custom header value: X-RequestVerificationToken.  This approach avoids complications in combining the ProxyApi automatically-generated POST data and a custom form field.

Because WebAPI is often used for non-browser-based access, the attribute also allows you to optionally specify any types of authentication (e.g. Basic) that should be excluded from the verification process.

Passing the Hidden Token to the Server

The JavaScript implementation of the proxy objects allows you to specify either a concrete value or an accessor function to get the form field value:

$.proxies.myController.antiForgeryToken = "1234abc";

// or

$.proxies.myController.antiForgeryToken = function() { 
    return $("#someField").val();

By default, this function will use jQuery to locate the hidden input generated by the Html.AntiForgeryToken() method and use it’s value.


Overall, this implementation is nothing groundbreaking.  It borrows heavily from the the SPA MVC template and from other examples online but it does allow ProxyApi to prevent CSRF attacks with minimal change to the code for developers.

The source code for this is available on GitHub, and the updated package is available for download via nuget.

Fallback Images with Knockout

After a busy few weeks at work I’ve finally managed to spend some time on knockout development again, and today I found a nice solution to a problem with data-bound images.

In my example I had a list of contacts that were being displayed on the page, and each contact had a URL linking to their profile image.

	Id: 1,
	FirstName: "Steve",
	LastName: "Greatrex",
	ProfileImage: "/some/image.jpg"

The binding to display the image is initially pretty simple – I can use the attr binding to set the src property on the img element using the vanilla knockout library.

<img data-bind="attr: { src: ProfileImage }" />

Simple enough, right?


Unfortunately some of my contacts don’t have a ProfileImage property.  Even worse, some of them do have a ProfileImage but it points to a non-existant image.

If I use the attr binding as above then I get an unpleasant looking “missing image” icon…


…when what I really want to do is use a placeholder image instead.

The img binding

To resolve this problem I created a new custom binding named img.  This expects a parameter containing an observable src property for the image URL, and either a hard-coded or an observable fallback URL to be used in case of null URLs or errors.

<img data-bind="img: { src: ProfileImage, fallback: '/images/generic-profile.png' }" />

The binding itself is nothing complicated.  As with all custom bindings you can optionally specify an update and an init handler that are called when the value changes and when the binding is initialised respectively.

For this binding, the update handler needs to check the value of both the src and fallback properties, then set the src attribute on the img to whichever value is appropriate.

The only thing that the init function needs to handle is the scenario where the image fails to load (using jQuery.error).

ko.bindingHandlers.img = {
    update: function (element, valueAccessor) {
        //grab the value of the parameters, making sure to unwrap anything that could be observable
        var value    = ko.utils.unwrapObservable(valueAccessor()),
            src      = ko.utils.unwrapObservable(value.src),
            fallback = ko.utils.unwrapObservable(value.fallback),
            $element = $(element);

        //now set the src attribute to either the bound or the fallback value
        if (src) {
            $element.attr("src", src);
        } else {
            $element.attr("src", fallback);
    init: function (element, valueAccessor) {
        var $element = $(element);

        //hook up error handling that will unwrap and set the fallback value
        $element.error(function () {
            var value = ko.utils.unwrapObservable(valueAccessor()),
                fallback = ko.utils.unwrapObservable(value.fallback);

            $element.attr("src", fallback);

That’s all there is to it – you can now specify a “primary” and a “fallback” binding for your images to get something like the effect below:


Another problem solved by the Swiss army knife that is knockout custom bindings.

Explicitly Controlling Cache Dependencies in MVC

In the past, I have always used the OutputCacheAttribute  when I wanted to cache the result of an Action in my MVC application; it’s simple, and it gets basic caching up and running with very little effort.

Unfortunately “simple and quick” are not quite as useful when you need a little more control…


Let’s say you have a resource that you automatically generate in your controller, but that creating that resource takes a long time…

public async Task<ActionResult> Slow()
	var resource = await _service.GenerateResource();
	// ...5 minutes later...
	return View(resource);

Understandably, you want to cache the result of this action so that subsequent visitors don’t all have to wait around for the resource to be created.  [OutputCache] to the rescue, right?

Not So Fast!

Unfortuantely, the resource is not entirely constant – it can be altered by certain user actions in other areas of the application, and when that happens it will need to be regenerated.

[OutputCache] will allow us to vary the cached result by a number of variables (host, action arguments, custom strings…) and supports timeouts etc, but it does not allow another piece of code somewhere in the application to say “that resource is not longer valid”.

An Alternative to [OutputCache]

One alternative means of caching the results of an action is to call the AddCacheDependency method on the Response object:

public async Task<ActionResult> Index()
	Response.AddCacheDependency(new CacheDependency(...));

The CacheDependency instance in this example is an ASP.NET class that is used by the caching framework to determine when the resource we created has been changed.

The base CacheDependency implementation allows you to specify one or more file system paths that will be monitored, and will invalidate itself when any of those files is updated.  There is also a SqlCacheDependency class that observes the results of a SQL query and invalidates when they change.

Neither of these implementations will give us quite what we are looking for –  the ability to invoke a method from anywhere within the codebase that explicitly marks the cached content as changed – but they are leading us in the right direction.

If we can create a CacheDependency instance that is uniquely identifiable for the slow resource then we can add it to the response and force it to invalidate itself at a later date.

Extending CacheDependency

Before we can get into how we add our CacheDependency instance, we need to create an implementation that will allow us to explicitly invalidate it through code.  Thankfully, CacheDependency exposes a number of methods to it’s inheriting classes that mean we can achieve our explicit invalidate very easily.

The minimum that we need to do to make the CacheDependency work is to pass a list of paths into the base constructor and to provide a valid value from the GetUniqueID method.  We know that we do not want to depend on any file system resources so we can just pass an empty list into the constructor, and as we need a unique ID anyway (to identify the cached resource later) we can just pass this into the constructor.

class ExplicitCacheDependency : CacheDependency
	private string _uniqueId;

	public ExplicitCacheDependency(string uniqueId)
		: base(new string[0]) //no file system dependencies
		_uniqueId = uniqueId;
	public override string GetUniqueID()
		return _uniqueId;

CacheDependency has a protected NotifyDependencyChanged method that will notify the caching framework that the cached item is no longer valid. In most implementations this would be invoked in some callback, but for our purposes we can just add a new Invalidate method and invoke it directly:

public void Invalidate()
	base.NotifyDependencyChanged(this, EventArgs.Empty);

Voila – a cache dependency that we can explicitly invalidate.  But how can we get a reference to this in the various places that we need it?


Creating a new cache dependency doesn’t help us much if we can’t get a reference to it later – otherwise, how can we call Invalidate?  Let’s create a new class that handles the creation and invalidation of the new cache dependencies: CacheDependencyManager.

class CacheDependencyManager
	private Dictionary<string, ExplicitCacheDependency> _dependencies
		= new Dictionary<string, ExplicitCacheDependency>();

	public CacheDependency GetCacheDependency(string key)
		if (!_dependencies.ContainsKey(key))
			_dependencies.Add(key, new ExplicitCacheDependency(key));

		return _dependencies[key];

	public void InvalidateDependency(string key)
		if (_dependencies.ContainsKey(key))
			var dependency = _dependencies[key];

Note: in the interests of brevity I have not included the thread-safe version here; this is a terrible idea in the real world, so make sure you include some appropriate locking!

This CacheDependencyManager is intended to hide the detail of how the dependency instances are created and invalidated from calling classes, which it achieves through 2 public methods:

  • GetCacheDependency that creates a new ExplicitCacheDependency if none exists for the specified key, or returns the cached one if it has been previously created
  • InvalidateDependency that attempts to locate an existing cache dependency for the specified key, and invalidates and removes it if one is found.  If one doesn’t exist then it does nothing, so callers don’t need to know whether or not the resource has already been cached

One quick singleton pattern later and we can call these methods from throughout our codebase. When we invoke our slow action for the first time we need to add the dependency to the response using a unique key to identify the slow resource:


And how do we invalidate the resource after some arbitrary user action? We can just pass that same key into the Invalidate:

public class SomeOtherController : Controller
	public ActionResult SomeRandomUserAction()

Obviously you could (should!) use dependency injection to pass the CacheDependencyManager to your controllers instead of accessing it directly, but the singleton will suffice for this example.

That’s All Folks

That’s the lot – now we can manually invalidate our slow resource whenever and from wherever we want, and our users can enjoy speedy cached resources the rest of the time!