random .NET and web development musings

I’m fed up of writing:

<%= Html.Encode(bla) %>

throughout my views. Not only is it messy, but ASP.NET’s default behaviour of “be as insecure as possible” means you have to remember to do this everywhere. In addition to this, it simply uses:


underneath, which isn’t particularly good at preventing XSS.

OpenRasta (a brilliant alternative to MVC which you should be using) has an excellent solution to this problem, by using a custom CSharCodeProvider to help with view compilation.

Below is a simplified version of the code OpenRasta uses, demonstrating how you can get automatic HTML encoding of all code expressions in your views. This also works for WebForms.

It uses an IoC service locator to request an arbitrary IHtmlEncoder. This allows you to use whatever encoding library you like, such as Microsoft AntiXss.

public class AutoHtmlEncodingCSharpCodeProvider : CSharpCodeProvider
	public AutoHtmlEncodingCSharpCodeProvider()

	public AutoHtmlEncodingCSharpCodeProvider(IDictionary<string, string> providerOptions) : base(providerOptions)

	public override void GenerateCodeFromStatement(CodeStatement statement, TextWriter writer, CodeGeneratorOptions options)
		var codeExpressionStatement = statement as CodeExpressionStatement;
		if (codeExpressionStatement != null)
			var methodInvokeExpression = codeExpressionStatement.Expression as CodeMethodInvokeExpression;
			if (methodInvokeExpression != null)
				if (methodInvokeExpression.Method.MethodName == "Write" && methodInvokeExpression.Parameters.Count == 1)
					var parameter = methodInvokeExpression.Parameters[0] as CodeSnippetExpression;

					if ((parameter != null) && (!string.IsNullOrEmpty(parameter.Value)))
						parameter.Value = "global::" + GetType().FullName + ".PreProcessObject(this, " + parameter.Value + ")";

		base.GenerateCodeFromStatement(statement, writer, options);

	public static string PreProcessObject(object source, object value)
		if(value is Raw)
			return ((Raw)value).Value;

		var encoder = ServiceLocator.Current.TryGetInstance<IHtmlEncoder>();
		if (encoder != null)
			return encoder.HtmlAttributeEncode(value.ToString());

		return HttpUtility.HtmlAttributeEncode(value.ToString());

public class Raw
	public string Value { get; set; }

	public static explicit operator Raw(string text)
		return new Raw { Value = text };

	public static implicit operator string(Raw output)
		return output.Value;

You need to register this in your Web.config like so:

		<compiler language="c#;cs;csharp" extension=".cs" warningLevel="4" type="MyAssembly.AutoHtmlEncodingCSharpCodeProvider, MyAssembly">
			<providerOption name="CompilerVersion" value="v3.5" />
			<providerOption name="WarnAsError" value="false" />

Then in your pages, you can do this:

<p><%= "<script>alert('i'm encoded, so i wont popup');</script>" %></p>
<p><%= (Raw)"<strong>i'm bold because im escaped with (Raw)!</strong>" %></p>

Which will be rendered as:

<script>alert(‘i’m encoded, so i wont popup’);</script>
i’m bold because im escaped with (Raw)!

There you go!

Because this code has been inspired by/copied from/a modification of code from OpenRasta, according to its license I must reproduce the copyright notice. If you also wish to use this code, you must do the same.

 Permission is hereby granted, free of charge, to any person obtaining
 a copy of this software and associated documentation files (the
 "Software"), to deal in the Software without restriction, including
 without limitation the rights to use, copy, modify, merge, publish,
 distribute, sublicense, and/or sell copies of the Software, and to
 permit persons to whom the Software is furnished to do so, subject to
 the following conditions:
 The above copyright notice and this permission notice shall be
 included in all copies or substantial portions of the Software.

In this post I’m going to discuss one method of implementing validation into your OpenRasta handlers using an OperationInterceptor.

OpenRasta deliberately doesn’t ship with a validation framework, there are plenty out there for you to use. For the purposes of this post, I’m not using any particular validation framework, simply demonstrating the point with a generic IValidator, something like:

public interface IValidator<TResource>
    ValidationReport Validate(object resource);

First, lets see a way you could do validation in an MVC sort of way:

public class EditUserHandler
    private readonly IValidator<EditUserResource> validator;

    public EditUserHandler(IValidator<EditUserResource> validator)
        this.validator = validator;

    public OperationResult Post(EditUserResource resource)
        var validationReport = validator.Validate(resource);

        if (!validationReport.IsValid)
            return new OperationResult.BadRequest {ResponseResource = resource};

        // save user details here

        return new OperationResult.SeeOther {RedirectLocation = "~/ "};

This is probably a very familiar pattern and something you could expect to see inside all hander operations which require validation. Meh. This duplication is not only wasteful, but its unnecessary noise cluttering up your Operation and we can get rid of it.

OperationInterceptors wrap the execution of an operation, giving you three places to interact, BeforeExecute, RewriteOperation and AfterExecute. In this instance, we are only concerned with BeforeExecution.

This method is called just before the Operation in invoked, this is where we want to examine the input parameters, and check if they are valid.

For the purposes of brevity, the below code assumes there is only one parameter to your operation method; hence the FirstOrDefault();

public class ValidationOperationInterceptor : OperationInterceptor
	private readonly IDependencyResolver resolver;
	private readonly ICommunicationContext context;

	public ValidationOperationInterceptor(IDependencyResolver resolver, ICommunicationContext context)
		this.resolver = resolver;
		this.context = context;

	public override bool BeforeExecute(OpenRasta.OperationModel.IOperation operation)
		var input = operation.Inputs.FirstOrDefault();

		if(input == null)
			return true;

		var parameter = input.Binder.BuildObject();

		var validatorType = typeof(IValidator<>).MakeGenericType(parameter.Instance.GetType());

		if (!resolver.HasDependency(validatorType))
			return true;

		var validator = this.resolver.Resolve(validatorType) as IValidator;

		var validationReport = validator.Validate(parameter.Instance);

		if (validationReport.IsValid)
			return true;
		// add validation errors here

		context.OperationResult = new OperationResult.BadRequest { ResponseResource = parameter.Instance };
		return false;

We register this OperationInterceptor as follows:

ResourceSpace.Uses.CustomDependency<IOperationInterceptor, ValidationOperationInterceptor>(DependencyLifetime.Transient);

The above code assumes that the parameter binding succeeded, I’ll demonstrate a way to deal with binding failures in a future post (its very similar to the above code).

So what effect does this code have? Well, it can make your handlers super clean:

public class EditUserHandler
    public OperationResult Post(EditUserResource resource)
        // save user details here

        return new OperationResult.SeeOther {RedirectLocation = "~/ "};

Your Operations are now only called when the resource is valid, excellent!

You may be seeing one obvious drawback with this approach, that being what if your resources need extra data setting on them before they get sent to the codec in the case of invalidity? When editing a user, perhaps the resource needs to also contain a list of possible authorization roles, one of which will be selected for the user. Having a single mechanism for handling validation for all types doesn’t allow you anywhere to set this extra information on the resource. Well, there is a solution I’ll be proposing in my next post.

So stay tuned :)

This is the 2nd part to my OpenRasta introduction (see part 1 here) in which I’m going to cover Handlers and OperationResults.

Handlers are very much like MVC Controllers, except that there is no base class or interface to implement 😀 This makes them incredibly lightweight and a dream to work with.

The OpenRasta equivalent of MVC Actions are Operations. These look very similar to their MVC counterparts except we return an OperationResult instead of an ActionResult.

OperationResults represent HTTP Status codes, and you should strongly consider the choice of OperationResult that you use.

public class FooHandler
    private readonly IFooService fooService;

    public FooHandler(IFooService fooService)
        this.fooSerivce = fooService;

    public OperationResult Get(int id)
        var foo = fooService.Get(id);

        if(foo == null)
            return new OperationResult.NotFound();

        return new OperationResult.OK(foo);

(similarly to my last post, I’ll ignore the fact that we shouldn’t be sending domain objects out of our handlers for brevity of the example)

In the above case, if the IFooService cannot find the request Foo object, we return an OperationResult.NotFound which is a direct representation of HTTP Status 404.

If it is found, we return an OK (HTTP 200) passing the Foo “resource” out as the ResourceResponse for encoding later in the pipeline.

OpenRasta code is designed with discoverability in mind, intellisense is your friend. Start typing:

new OperationResult.

and see the complete list of HTTP Statuses you can return. Different results have different arguments, for example:

new OperationResult.SeeOther {RedirectLocation = "~/somewhere" }

In OpenRasta, Operations have the name of the HTTP Verb you want them to respond to (you can override this behaviour with named operations, more on this later).

This means that you have a Handler per Resource, which is an excellent means of helping enforce S.R.P.

The last part we need is the registration.


The brilliant fluent configuration API makes the above code very self explanitory, but just to clarify:

ResourceSpace.Has.ResourcesOfType<Foo>() // Tell OpenRasta about our Foo type
    .AtUri("/foo/{id}") // Providing the URI where Foos reside. The brackets are parameter templating just like MVC
    .HandledBy<FooHandler>() // Here we tell OpenRasta which class handles requests for Foos
    .RenderedByAspx("~/Views/Foo.aspx"); // Here we set a WebForms codec, using the given view

How much simpler could this be?

Next post we’ll look at Pipeline Contributors

Huddle are hosting an OpenRasta Code Camp on the 18th February at their London offices. You want to go to this.

You can read more about the event here and register for the event here.

You haven’t heard of OpenRasta? For those living under a rock, to quote from the wiki:

OpenRasta is a resource-oriented framework for .NET enabling easy ReST-ful development of web sites and services. OpenRasta is designed to run on .net 2.0 and above, and can co-exist peacefully with your existing ASP.NET and WCF deployments.

However, this statement alone does not come close to describing the awesomeness of OpenRasta.

OpenRasta is “resource-oriented”, this really cannot be understated. OpenRasta elegantly embraces the way HTTP is designed which immediately removes countless issues you encounter when using the likes of ASP.NET MVC.

For those who need an HTTP referesher, consider URIs. The clue is in the name, Uniform RESOURCE Identifier. A resource can be anything, to take Seb’s example from his Progressive.NET talk, a teacup.

Now you can’t send a teacup over the wire, but we can send an encoded projection. In MVC, you might do something like:

public ActionResult Get()
    var cup = teacupService.Get();
    return View("TeaCup", cup);

which will use the WebForms view engine to combine the TeaCup.aspx template with the cup resource (I’m going to overlook the fact that you shouldn’t be sending your domain objects out directly for brevity).

This is ok, but what happens when you want the teacup in JSON format? You can do one of two things. Either you create a whole new Action method:

public ActionResult GetAsJson()
    var cup = teacupService.Get();
    return Json(cup);

which immediately creates all sort of code smells; duplication, encoding concerns in the method names (and therefore url) and the method itself. Meh.

Or you could remove some of this duplication by having a single action method and checking the accept headers yourself inside the action method, but come on, seriously. Why should you have to do all this boilerplate/plumbing code yourself? I might as well just be using an HTTP Handler. What power is the Controller giving you if you’re having to do everything yourself?

Do not fear. OpenRasta is here! Lets see how we do the same thing in OpenRasta:

public class TeaCupHandler
    public OperationResult Get()
        var cup = teacupService.Get();
        return new OperationResult.OK(cup);

(obviously I’m ignoring error handling here)

But wait, I hear you cry! Where do I specify the encoding? In the configuration of course, somewhere completely separate to the above handler method, as it isn’t its concern.


Look at that! One line of code for each type of encoding we want! *joys* The lovely fluent `.And.` allows you to chain up as many different types of encoding support as you like. And because OpenRasta is completely pluggable and extendible (no, it REALLY is, not like in the way MVC claims) you can write your own codecs with extreme ease.

So, that was a very brief introduction to encoding in OpenRasta. In future posts I will cover HTTP verbs and handlers in greater detail, and show you the power of the pipeline!