Oh it’s fine if you use Internet Explorer. Or Chrome for that matter. But every request issued from Firefox to WebDev.WebServer.Exe seems to have about a full second of lag added. If your pages host multiple images and CSS files, it’s intolerable.

It works on your machine

What’s that you say – you haven’t experienced this problem? Lucky you! I’ve asked other developers about this, and they all claim it’s fine on their machine too. And a quick Google search doesn’t turn up any other reports of the issue.

But I’ve had four different physical development PCs in the last couple of years, running three major different OS versions, two major different versions of Visual Studio and two major different versions of Firefox, and still have been wading through treacle every single time! Firefox is way faster communicating with servers on the other side of the planet than with this particular web server hosted on the same PC. What gives?

The conspiracy theorist in me even wondered if some evil person in Microsoft had hard-coded this behaviour into VS, intending to discourage web developers from working exclusively in Firefox. I confess I even changed my Firefox UserAgent string to match MSIE, but that didn’t help.

The solution

Finally! It turns out to be something to do with IPv6. I don’t know whether the problem is in Firefox or in WebDev.WebServer.Exe, but disabling Firefox’s IPv6 support is like cutting off the ball and chain. Suddenly, communication with the local server is back to the blistering pace you’d expect.

All you need now is instructions for disabling Firefox’s IPv6 support.

Phil Haack, ASP.NET MVC program manager, just posted a prototype application structured in that way. It’s a really neat solution, and overcomes a number of issues that others, including myself, have experienced when trying to do it previously.

In this post, I’m going to take Phil’s prototype and tweak it in a few ways to my liking. That’s not to say that there’s anything wrong with his design, but only that I want to throw in some extra ideas that might make it even slicker in some cases.

How it works

The mechanism as given comes in two parts:

• Routing configuration: There’s an extension method on RouteCollection called MapAreas() which lets you register a URL pattern for multiple areas. You pass it a URL pattern, a controller “root namespace”, and an array of area names. It prefixes “{area}/” to your URL pattern, and for each area name, it registers a route entry that targets controllers who live in the namespace given by: 
  (root namespace + “.Areas.” + area name + “.Controllers”)
• View engine: There’s a special view engine called AreaViewEngine that uses a built-in convention to look for view templates in an area-specific folder.

Don’t worry if you don’t understand this. If you download Phil’s prototype and try it, you’ll find it’s all straightforward enough.

It works very nicely, and it uses a clever trick with route defaults and constraints so that when you’re generating outbound URLs, you can link to controllers/actions in any area by specifying the area name in your Html.RouteLink() call, or you can link to controllers/actions within the same area using a normal Html.RouteLink() call that doesn’t specify any area name.

Suggestions for enhancement

I’m not going to touch the view engine part of the prototype at all. All I want to achieve is a configuration system that’s slightly more natural (for me) and a modified set of conventions and rules that are a bit more flexible. Here’s how I’d like a simple areas routing configuration to look:

// Routing config for the blogs area
routes.CreateArea("blogs", "AreasDemo.Areas.Blogs.Controllers",
    routes.MapRoute(null, "blogs/{controller}/{action}", new { controller = "Home", action = "Index" })
);
 
// Routing config for the forums area
routes.CreateArea("forums", "AreasDemo.Areas.Forums.Controllers",
    routes.MapRoute(null, "forums/{controller}/{action}", new { controller = "Home", action = "Index" })
);
 
// Routing config for the root area
routes.CreateArea("root", "AreasDemo.Controllers",
    routes.MapRoute(null, "{controller}/{action}", new { controller = "Home", action = "Index" })
);

… and here’s an example of a very slightly more complex configuration:

// Routing config for the blogs area
routes.CreateArea("blogs", "AreasDemo.Areas.Blogs.Controllers",
    routes.MapRoute(null, "SpecialUrlForPosts", new { controller = "Home", action = "Posts" }),
    routes.MapRoute(null, "blg/{controller}/{action}/{id}", new { action = "Index", controller = "Home", id = "" })
);
 
// Routing config for the forums area
routes.CreateArea("forums", "AreasDemo.Areas.Forums.Controllers",
    routes.MapRoute(null, "myforums/SecretAdminZone/{action}", new { controller = "Admin", action = "Index" }),
 
    // Equally possible to construct routes using "new Route()" syntax too
    new Route("myforums/{controller}/{action}", new MvcRouteHandler()) {
        Defaults = new RouteValueDictionary(new { controller = "Home", action = "Index" })
    }
);
 
// Routing config for the root area
routes.CreateArea("root", "AreasDemo.Controllers",
    routes.MapRoute(null, "{controller}/{action}", new { controller = "Home", action = "Index" })
);

The point to notice is that each area is configured independently of the others, which for me feels more natural than defining a single URL pattern that for some reason applies to all areas.

It turns out to be dead easy to make it work like this. All you need is this simple CreateArea() extension method:

public static void CreateArea(this RouteCollection routes, string areaName, string controllersNamespace, params Route[] routeEntries)
{
    foreach (var route in routeEntries)
    {
        if (route.Constraints == null) route.Constraints = new RouteValueDictionary();
        if (route.Defaults == null) route.Defaults = new RouteValueDictionary();
        if (route.DataTokens == null) route.DataTokens = new RouteValueDictionary();
 
        route.Constraints.Add("area", areaName);
        route.Defaults.Add("area", areaName);
        route.DataTokens.Add("namespaces", new string[] { controllersNamespace });
 
        if (!routes.Contains(route)) // To support "new Route()" in addition to "routes.MapRoute()"
            routes.Add(route);
    }
}

Apart from that, there’s no difference from the original prototype (well, you can delete the original prototype’s MapAreas() and MapRootArea() methods: they’re no longer used).

Benefits

How does this differ from the original prototype? What conventions have changed?

• URL patterns are no longer forced to start with the area name (though they can if you want). Within a single area, you can have some URLs that start with the area name, and some that don’t.
• In fact, URL patterns are now totally independent of area names, which means your area names can simply be internal code words for software modules, never seen by the public. If that’s what you want.
• Controller namespaces are independent of area names, and they don’t even have to be constant within a single area. Pick your own convention and follow it.
• You can  configure each area’s routes in a separate block of code, using a sweet DRY syntax, which for me feels more natural than having a single method call that registers routes across all areas.
• You don’t need any special code or configuration for the “root” area – that’s just another area like the others, usually just with shorter URL patterns.
• You can keep using the familiar routes.MapRoute() and new Route() ways of building route entries, merely wrapping up groups of them in CreateArea() calls. No significant new API.

Apart from this, it uses almost exactly the same mechanism as in the original prototype.

Drawbacks

If enforcing conventions is your thing, then you might not appreciate the extra flexibility that comes with these changes.

Also, when you do cross-area links, you have to be careful to specify a controller name and not just assume the default controller will be used. Otherwise, the generated URL might reuse the current request’s controller name, which might not even exist in the destination area. This is because of an obscure technicality in how URL generation works (it doesn’t affect Phil’s original design because of how he requires all URLs to start with an “{area}” segment).

This isn’t worth explaining in detail – all I’ll say is that the solution is simply to make sure your cross-area links always specify a controller name. Of course, you almost certainly should be doing that anyway, because it would be very weird to link just to an action name on a different area without being clear about which controller hosts that action.

Summary

ASP.NET MVC continues to impress me with its flexibility. If you want to structure your app in terms of “modules” or “areas”, it doesn’t take much code to enable it. Phil’s approach to areas is the neatest I’ve seen so far. Personally I like the tweaks I’ve suggested above, but it’s subjective and you can do things your own way.

DeveloperDeveloperDeveloper! Day is a free one-day event run by the UK .NET community for the UK .NET community. It’s among the largest such events in the UK, so I’m excited to be presenting a session! Judging by the list of speakers and the event’s reputation, quality should be pretty high, and the technical content should be pretty deep.

Registration has just opened, but be warned: it will likely sell out within the next 24 hours…

• Data caching, which lets you cache arbitrary .NET objects in an HttpContext’s Cache collection. You can specify expiration rules and cache entry priorities.
• Output caching, which tells pages and user controls to cache their own rendered output and re-use it on subsequent requests. This is designed to sit neatly in WebForms’ system of server control hierarchies.

Data caching continues to work perfectly well in ASP.NET MVC, because it’s just about getting objects in and out of a collection, and isn’t specific to any particular UI technology.

If only output caching was so simple! ASP.NET’s output caching facility is deeply stuck in WebForms thinking, which makes it problematic in ASP.NET MVC. You could try to use ASP.NET output caching with ASP.NET MVC, but then you’d have the following issues:

• No usable support for partial caching. ASP.NET output caching can cache complete responses or individual server controls, but hang on: we’re not using server controls in ASP.NET MVC, so all that’s left is complete response caching.
• Bypasses authorization and other filters. ASP.NET output caching runs very early in the request-processing pipeline (see HttpApplication’s ResolveRequestCache event), long before MVC comes in with its controllers, actions, and filters. It can’t behave like an action filter is supposed to. See update below.

Unfortunately, the [OutputCache] filter that ships with ASP.NET MVC is merely a thin wrapper around ASP.NET output caching, so it has exactly those problems. The MVC team have explained that they’re aware of the issues, but it’s very difficult to make ASP.NET output caching fit into MVC’s design, and they are focusing on other things first. And personally I’m happy with that: I’d rather see a finished 1.0 RTM release this year than fuss about output caching.

Fixing it ourselves

One reason why I don’t mind [OutputCache]’s limitations so much is that ASP.NET MVC is extremely extensible, and without too much trouble we can replace the output caching system with something new and more suitable.

We can quite easily create a new caching filter that captures actions’ output and uses ASP.NET’s data caching facility to store it for next time. This filter will fit properly into the MVC pipeline, not strangely bypassing authorization or other earlier filters (it will run at the right time in whatever ordered set of filters you’ve using). And if you’re using something like the PartialRequest system for widgets that I described yesterday, it will naturally let you cache PartialRequests’ output separately from the actions that host them, which is also known as partial output caching.

I must first acknowledge that the following code is very similar to the custom output caching filter that Maarten Balliauw presented way back in June. The reason I think this warrants a whole new post is because the following code works better for partial caching with PartialRequest and with MVC Contrib’s subcontrollers, and because it would be good for more MVC developers to discover it. But Maarten was first to write a good blog post on this subject.

So here it is. Drop the following class somewhere in your MVC project:

public class ActionOutputCacheAttribute : ActionFilterAttribute
{
    // This hack is optional; I'll explain it later in the blog post
    private static MethodInfo _switchWriterMethod = typeof(HttpResponse).GetMethod("SwitchWriter", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);
 
    public ActionOutputCacheAttribute(int cacheDuration)
    {
        _cacheDuration = cacheDuration;
    }
 
    private int _cacheDuration;
    private TextWriter _originalWriter;
    private string _cacheKey;
 
    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        _cacheKey = ComputeCacheKey(filterContext);
        string cachedOutput = (string)filterContext.HttpContext.Cache[_cacheKey];
        if (cachedOutput != null)
            filterContext.Result = new ContentResult { Content = cachedOutput };
        else
            _originalWriter = (TextWriter)_switchWriterMethod.Invoke(HttpContext.Current.Response, new object[] { new HtmlTextWriter(new StringWriter()) });
    }
 
    public override void OnResultExecuted(ResultExecutedContext filterContext)
    {
        if (_originalWriter != null) // Must complete the caching
        {
            HtmlTextWriter cacheWriter = (HtmlTextWriter)_switchWriterMethod.Invoke(HttpContext.Current.Response, new object[] { _originalWriter });
            string textWritten = ((StringWriter)cacheWriter.InnerWriter).ToString();
            filterContext.HttpContext.Response.Write(textWritten);
 
            filterContext.HttpContext.Cache.Add(_cacheKey, textWritten, null, DateTime.Now.AddSeconds(_cacheDuration), Cache.NoSlidingExpiration, System.Web.Caching.CacheItemPriority.Normal, null);
        }
    }
 
    private string ComputeCacheKey(ActionExecutingContext filterContext)
    {
        var keyBuilder = new StringBuilder();
        foreach (var pair in filterContext.RouteData.Values)
            keyBuilder.AppendFormat("rd{0}_{1}_", pair.Key.GetHashCode(), pair.Value.GetHashCode());
        foreach (var pair in filterContext.ActionParameters)
            keyBuilder.AppendFormat("ap{0}_{1}_", pair.Key.GetHashCode(), pair.Value.GetHashCode());
        return keyBuilder.ToString();
    }
}

Now you can use [ActionOutputCache] instead of MVC’s built-in [OutputCache]. The advantage of [ActionOutputCache] is that it’s a fully native MVC action filter, and doesn’t rely on or inherit the problems of ASP.NET’s WebForms-oriented output caching technology. So, for example, [ActionOutputCache] plays nicely with MVC’s [Authorize] filter. Update: Since the beta release, the built in [Authorize] and [OutputCache] filters now play nicely together too.

You can use [ActionOutputCache] to cache the output of any action method just like [OutputCache], but it’s perhaps most interesting when you combine it with the PartialRequests method of rendering widgets (or use it with Html.RenderAction(), which isn’t compatible with the built-in [OutputCache]). Put an [ActionOutputCache] attribute on the widget’s action method (not on the action that hosts it), then you’ll have partial page caching, as shown in the following code.

public class BlogController : Controller
{
    [ActionOutputCache(60)] // Caches for 60 seconds
    public ActionResult LatestPosts()
    {
        ViewData["currentTime"] = DateTime.Now;
        ViewData["posts"] = new[] {
            "Here's a post",
            "Here's another post. Marvellous.",
            "Programmer escapes from custody"
        };
        return View();
    }
}

This is great if your widget displays some relatively static data (e.g., a list of the “most recent” things), or is an action method whose output is constant for a given set of parameters (e.g, a dynamically-built navigation menu that highlights the visitor’s current location, where the current location is one of the parameters passed to the action method), and you don’t want to recompute it on every page hit.

Support for partial caching is a major advantage of PartialRequest over the use of viewdata-populating filters and partial views to render widgets. The filter/partialview technique can never support proper output caching, because inherently it mixes the widget’s viewdata with the main page’s viewdata, and the two can’t be distinguished by the time you’re actually rendering the view. The closest you could get would be to limit yourself to data caching, but that’s more complex and not always viable anyway, such as if you’re using an IQueryable to defer a SQL query until view rendering time.

Notes

To keep the [ActionOutputCache] code short and easy to understand, and because its current behaviour is adequate for my own current project’s needs, there are a number of limitations and caveats you should know about:

• It uses reflection to access HttpResponse’s private SwitchWriter() method. That’s how it’s able to intercept all the output piped to Response during subsequent filters and the action method being cached. It’s unfortunate that SwitchWriter() is marked private, but it is. If you don’t want to bypass the “private” access modifier this way, or if you can’t (e.g., because you’re not hosting in full-trust mode), then you can download an alternative implementation that uses a filter to capture output instead. This isn’t quite as straightforward, but some people will prefer/need it.
• It’s hard-coded to generate cache keys that vary by all incoming action method parameters and route values, and not by anything else. You would have to modify the code if you needed the ability to vary cache entry by other context parameters (such as unrelated querystring or form values).
• When generating cache keys, it assumes that the action method parameter types and route value types all have sensible implementations of GetHashCode(). This is fine for primitive types (strings, ints, etc.), but if you try to use it with a custom parameter types that have no proper implementation of GetHashCode(), it will pick a different cache key every time and appear not to be caching. So implement GetHashCode() properly on any such custom parameter types.
• It doesn’t attempt to cache and replay HTTP headers, so it’s not suitable for caching action methods that issue redirections.

In other words, it works great for most straightforward widget output caching scenarios, but if you’re doing something more complex then please be prepared to dive into the code yourself! Hope this is useful to a few people.

So, you’ve got basically two options:

1. Make sure each action prepares an absolutely complete set of ViewData for not just the main page you’re rendering but also for every widget it hosts. Then in your view you can render widgets by calling <% Html.RenderPartial(…) %>, passing to the partial view template the subset of ViewData needed to render that widget.
2. Allow actions or views to invoke other actions, spinning off multiple internal mini-MVC pipelines that prepare and render each widget.

Incidentally, this is exactly the same choice on offer to Ruby on Rails developers, who face the exact same issue. However, in Rails-world, option 2 is frowned upon because of the framework’s performance issues. But we don’t need to have that problem in ASP.NET MVC.

These two options are both perfectly usable in ASP.NET MVC, and each has its strengths and is suited to different circumstances.

Option 1 keeps your MVC pipeline simple and elegant, but it struggles to scale up in complexity if you have many widgets or hierarchies of widgets that appear or disappear at different times. It’s nice to use filter attributes to inject the ViewData elements needed for each widget, but not nice if there are many.

Option 2 is conceptually much simpler and enables simpler code, though at runtime there are more moving parts. It’s more like having a collection of genuinely independent widgets.  This is what you get with <%= Html.RenderAction(…) %> (which is sadly relegated to the MVC Futures assembly and has been left with some technical problems), and also with MvcContrib’s new idea of subcontrollers.

You’re free to choose the option that works best for you in any individual case. If someone tells you that internal subrequests (option 2) are bad because it “isn’t MVC”, then just bite them on the face immediately. Also ask them why they’re still willing to use Ajax, and even <IMG> tags for that matter, given that both are a form of subrequest.

About subcontrollers

Firstly, thankyou to the MVC Contrib guys, because the subcontrollers idea is neat and genuinely improves on what we had before with Html.RenderAction().

The core idea of subcontrollers is putting into ViewData a delegate for each widget. The view can render the widget by invoking the delegate. This allows the view to be totally ignorant of the widget it’s rendering, leaving the controller in full control. That eliminates the main problem people had with Html.RenderAction(). Brilliant!

What I don’t like so much about MVC Contrib’s subcontrollers is that it’s quite a heavyweight and complex solution. Firstly you have to be using MVC Contrib, and then you have to learn a non-obvious set of new conventions, and an alternative controller base class, and do something funny with your default model binder. I think it’s possible to get virtually all the same benefits (and some extra ones) with a utility class that’s just 17 lines long.

Partial Requests are easy

You’ve heard of partial views, so how about partial requests? Within any MVC request, you can set up a collection of internal partial requests, each of which can set up its own internal partial requests and so on. Each partial request renders a plain old action method in any of your plain regular controllers, and each can produce an independent widget. I’m calling them partial “requests” rather than “controllers” because they run a proper MVC request-handling pipeline that’s compatible with your routing system and your controller factory. Still, as with subcontrollers, all the control remains in controllers, and the view can be ignorant.

Drop this class somewhere in your MVC project:

public class PartialRequest 
{
    public RouteValueDictionary RouteValues { get; private set; }
 
    public PartialRequest(object routeValues) {
        RouteValues = new RouteValueDictionary(routeValues);
    }
 
    public void Invoke(ControllerContext context)
    {
        RouteData rd = new RouteData(context.RouteData.Route, context.RouteData.RouteHandler);
        foreach (var pair in RouteValues)
            rd.Values.Add(pair.Key, pair.Value);
        IHttpHandler handler = new MvcHandler(new RequestContext(context.HttpContext, rd));
        handler.ProcessRequest(System.Web.HttpContext.Current);
    }
}

Now, when you want to attach a widget to your output, you can put a partial request into view data as so:

ViewData["latestPosts"] = new PartialRequest(new { 
    controller = "Blog", 
    action = "LatestPosts" 
});

… then wherever you want to display that widget in your view, put:

<% ((PartialRequest)ViewData["partialAction"]).Invoke(ViewContext); %>

… or if you prefer, use this trivial Html.RenderPartialRequest() helper:

public static class PartialRequestsExtensions
{
    public static void RenderPartialRequest(this HtmlHelper html, string viewDataKey)
    {
        PartialRequest partial = html.ViewContext.ViewData.Eval(viewDataKey) as PartialRequest;
        if (partial != null)
            partial.Invoke(html.ViewContext);
    }
}

Now, having imported the relevant namespace, your view can simply contain:

<% Html.RenderPartialRequest("latestPosts"); %>

Assuming you have a regular BlogController with an action called LatestPosts, which might render its own view (have it render an MVC View User Control rather than an entire MVC View Page) or might simply return a ContentResult, you’ll find that its output is injected at the appropriate point in your view.

Of course, this works seamlessly with whatever arrangement of controller factories, model binders, and action invokers you might be using, and it executes any filters that surround the partial request’s target action method.

It’s testable, too: your unit tests can pick the PartialRequest object out of ViewData, and inspect its RouteValues collection, so check it’s invoking the expected target.

It naturally supports hierarchies of widgets, too: the action that a PartialRequest calls can fill its own independent ViewData collection with other PartialRequest objects, and invoke them from its own view, and so on.

It works well with Ajax, too: since your widget is the output of a plain old action method, you could use an Ajax request to re-fetch the widget’s contents and update it in the DOM without a full page refresh.

There’s one other major benefit, too, but I’m going to save that until tomorrow, because it’s cool enough to warrant a follow-up post in its own right…

What: “Writing about ASP.NET MVC“
Where: UWE (University of the West of England), Frenchay, Bristol (see FAQ for directions and a map) - Room 2q50 (in Q block)
When: Thursday 16th October 2008, 6:30pm (Doors open 6:00pm)
How to sign up

I’ll be talking about the ASP.NET MVC book I’m writing at the moment, but perhaps more interestingly, about the whole subject of writing a software book.

• Who can write a software book?
• How do you get a contract with a major publisher?
• How good is the money? What other benefits do you get?
• How much time and effort does it take? How does the editing process work?
• Is it for you?

It will be a short talk, because the main event that evening is Liam Westley’s talk, entitled Virtualisation for developers - What, Why, Where?.

With apologies to Oren Eini, whose talks at the same venue earlier in the same week are now unlikely to get many - if any - attendees, because of the massive enthusiasm and anticipation for mine and Liam’s blockbuster performances.

So, let’s start with the new technology. MVC Preview 5 comes with two new API pieces that seem relevant to validation:

• ModelState. Controllers now have an official way to pass validation error information to views. Populate ViewData.ModelState, then you can use the built-in HTML helpers to render error message summaries, and to highlight input fields that correspond to errors.
• Model binders. Controllers are expected to populate model objects from form posts using the IModelBinder API. You can create custom binders - the framework calls your binder to obtain a value for each model property. (If you don’t understand this, don’t worry - it turns out not to be relevant.)

The obvious thing to do (and I’ve seen several forum posts and blog comments suggest this) is to make a custom model binder that applies validation rules (maybe ones expressed as attributes on model properties, such as [IsRequired]) and populates ModelState with any errors it finds. However, there are technical issues that make such a design unworkable in Preview 5 (model binders don’t get told what type of model object they’re providing values for). And more importantly than the current technical issues, that sort of design would be totally undesirable anyway. Validation has nothing to do with controllers binding form posts to model objects, as I’ll explain.

In the last week, Scott Guthrie posted about handling form posting/validation scenarios in ASP.NET MVC, and so did Stephen Walther. The following design has some things in common with each of their designs, but some important differences too.

Basic principles

So, how do you design a pattern for validation? Like any design, start by deciding what characteristics are really important to you, and build from there. Here’s what I consider to be important truths of validation:

1. Model objects should perform and enforce validation at the appropriate time.
2. Validation rules should be expressible in plain old C#.
3. Validation rules and business rules are at opposite ends of the same spectrum.
4. Errors should bubble up to the UI automatically (no code needed).
5. Client-side validation is optional - it’s purely for convenience.

And what does that mean?

[1] says that model objects don’t merely hold validation rules (e.g., as attributes on their properties), but model objects also actually enforce those rules. So, it’s not acceptable for a controller class to make the decision to validate (as they do in many other examples) - that would undermine the model’s encapsulation, and would mean that a badly-behaved controller could choose to skip validation. It’s the model that enforces validation, and it does so at a time of its own choosing - usually when something is being committed (e.g., when the model object is being saved to the database), but it might also choose to validate simple property formatting rules during property setters.

Now, if the model is capable of enforcing validation at a time of its own choosing, then it needs a general-purpose mechanism to forcibly abort certain controller operations when validation rules are violated. Fortunately, C# comes with the perfect mechanism: exceptions. There’s nothing clever about this (simplicity is the goal) - when the model decides it won’t allow an operation, it throws an exception. The operation is forcibly aborted. The controller must obey.

Also, bear in mind that certain validation rules can only be enforced at the point of committing data or finalizing actions. For example, “usernames must be unique” will probably be enforced in your database (with a UNIQUE constraint). You therefore can’t rely on a single “validation” moment - the model has to be free to issue rule exceptions at any point during its processing, and the controller shouldn’t need any special-case logic to deal with this. This requirement fits quite easily into the following design.

[2] just says that I don’t want to rely on any kind of rules engine. Now I’m perfectly happy to have reusable attributes to represent certain simple property formatting rules (e.g., [IsRequired], [DataFormat(Formats.EmailAddress)]), and you could even build a custom rules engine, but these are built on the fact that arbitrary C# is allowed.

[3] tries to clarify that simple property formatting rules (e.g., must be valid SSN) are a good start, but not adequate on their own. Certain business rules describe whether or not an operation is allowed (e.g., usernames must be unique), might relate to interactions of multiple properties, might involve arbitrarily complex logic, and these ought to fit into the validation framework too. See the diagram below.

[4] is about making the system easy to maintain. When I add a new validation rule to my model, I want all controllers/views that work on that model type to render suitable error messages automatically, without changing any controller/view code.

Now, remember that when the model decides some rule has been violated, it throws an exception. If that exception is of some special type (let’s call it BusinessRuleException), then that exception can describe in some strongly-typed way which rule was validated and how. In fact, it can describe multiple rule validations simultaneously. All we need now is for controllers to catch BusinessRuleExceptions, use them to populate ViewData.ModelState, then ASP.NET MVC’s built-in helpers will take care of displaying the messages. We can do localization in this step too, for multilingual error messages.

[5] says that it’s nice to have a helper to generate client-side validation code automatically, but the helper doesn’t have to replicate every rule on the client. Obviously, since we’re allowing arbitrary C# rules, there’s no automatic translation of arbitrary rules to JavaScript. Sometimes client-side validation is impossible anyway (e.g., “usernames must be unique”). However, if some simple property formatting rules are implemented as attributes (e.g., [IsRequired]), then we can generate client-side code from these attributes. It won’t cover all rules, but it will cover many of them, and that’s good enough.

Time for some code plz

Yes I know - reading English is hard work. Far easier if I show you some C# code. Here’s how a model class might look:

public class Person
{
    [Required] [StringLength(20)] 
    public string Name { get; set; }
 
    [Required] [Range(1, 200)] 
    public int? Age { get; set; }
 
    public void EnsureValid()
    {
        // If any of this object's property values conflicts with a validation [Attribute],
        // it will add an entry to the violations collection
        RuleViolations violations = ValidationHelpers.RunValidationAttributes(this);
 
        // Now we can run any other custom C# validation logic
        if(Age.HasValue && ((DateTime.Now.Year - Age.Value) % 4 == 0))
            violations.Add(new ArbitraryViolation("Age", "Sorry, you were probably born on a leap year, so we won't let you register."));
 
        if (!violations.IsEmpty)
            throw new BusinessRuleException(violations);
    }
}
 
public static class PersonRepository
{
    public static void SavePerson(Person person)
    {
        // The model is reponsible for deciding when to validation.
        // It chooses to validate now. If there's a violation, it will
        // throw an exception
        person.EnsureValid();
 
        // Good - it was valid. Todo: now save to database
    }
}

As you can see, there are some simple property format rules implemented using attributes (these are the standard ones shipped in System.ComponentModel.DataAnnotations), but these are just a special case. You can of course use arbitrary C# logic when enforcing validation.

I don’t need to have a special method marked as the validation method (or an IValidatable interface or anything like that), because the model layer makes its own decision when to validate, and chooses how to do that. It just has to throw a BusinessRuleException if there’s a problem. In this example, it chooses to enforce validation before writing to the database, but you could choose to validate certain properties during their setter methods if you wanted.

Next, how does a controller look? It follows a general pattern like the following. The critical bit is that model operations are wrapped in a try…catch so that it can recover from errors and display suitable UI feedback.

public class RegistrationController : Controller
{
    [AcceptVerbs("GET")]
    public ViewResult Edit() { return View(new Person()); }
 
    [AcceptVerbs("POST")]
    public ActionResult Edit(string unused)
    {
        Person model = new Person();
        try
        {
            if (!TryUpdateModel(model, new[] { "Name", "Age" })) // At some point it may be possible to have a custom binder that throws a BusinessRuleException if there were setter exceptions, but as of Preview 5, have to use the slightly hacky TryUpdateModel()
                throw new BusinessRuleException();
 
            // The real validation happens to be enforced by the model here, but that's no concern for the controller
            PersonRepository.SavePerson(model);
 
            // The operation completed successfully (so validation must have passed)
            return RedirectToAction("Completed");
        }
        catch (BusinessRuleException ex)
        {
            // Generate suitable localized UI feedback based on exception that was thrown
            ex.AddToModelState(ViewData.ModelState);
            // Re-render edit screen
            return View(model);
        }
    }
}

Notice the call to ex.AddToModelState(ViewData.ModelState);. I’ve implemented that as an extension method on BusinessRuleException (so as not to mix ASP.NET MVC concerns with the core BusinessRuleException class) - it simply iterates through the list of RuleViolations objects, and generates/adds some localized UI feedback to ViewData.ModelState for each violation.

I haven’t included the full source code here because it’s still all a bit proof-of-concept, but it’s not too hard to fill in the gaps and get a working implementation.

And what of client-side validation?

As we discussed earlier, not all rules can be translated to client-side validation code. However, since some of the simpler rules (those on the green end of the validation-businessrule spectrum) are often implemented as System.ComponentModel.DataAnnotations attributes, it would be a straightforward job to make a Html.ClientSideValidation(object model) helper that dynamically generates suitable validation JavaScript. This bit is essentially the same as what I implemented in my previous MVC validation post.

Of course, you could have a pluggable system to generate a JS validation configuration suitable for multiple client-side validation frameworks.

About setter exceptions

As mentioned earlier, sometimes it’s desirable to enforce validation rules in property setters. This gives you solid assurance that your model object can’t have invalid property values, because when *any* code (an MVC controller or model binder, or some other domain or service code) tries to manipulate the model object, they’ll never get away with setting invalid property values. This strategy applies only to simple individual property formatting rules (the green end of the spectrum).

When setters throw exceptions, MVC Preview 5’s DefaultModelBinder is clever enough to capture them one property at a time, building up a ModelState structure. Unfortunately, at present, it disregards the exception type, so you can’t use it to generate suitable UI feedback later. I’ve asked for this to be fixed - let’s be optimistic that the MVC team will give tighter support for setter exceptions in the next update.

Now, here’s an interesting twist. If we want some validation rules to be enforced in setters, and those rules are expressed as [Attributes], then wouldn’t it be cool if that logic was automatically injected into the setter by the attribute? This gets us into aspect-oriented programming territory (AOP). Unfortunately the .NET CLR doesn’t have much support for AOP. PostSharp is the best option we’ve got, but it does require a special code compilation process.

If instead of using the System.ComponentModel.DataAnnotations attributes we used custom attributes, then they could implement PostSharp’s special interfaces. Then, when you compile with PostSharp, the attribute’s simple validation logic can automatically get injected into the property setter. However, if you don’t compile with PostSharp, then the logic wouldn’t automatically get injected into the setter, and you’d cleanly fall back on the behavior I showed earlier in this post.

Of course, this would only be useful if ASP.NET MVC gets better support for setter exceptions.

So, would you do validation like this?

Long post… sorry! Dear readers, I’d be very pleased to hear of any feedback on this design. If there’s any consensus on how it should work, then I or someone else could work it up into a downloadable reusable set of components and classes. This would include:

• The BusinessRuleException class that you can throw from your model layer to signal and describe arbitrary invalid user actions. It would hold a set of strongly-typed RuleViolation classes (e.g., RequiredFieldViolation, StringLengthViolation) that your controller or view can use to generate localized UI feedback
• Support for running System.ComponentModel.DataAnnotations attributes against a model object, to produce a collection of RuleViolation objects if there were problems
• A custom model binder that knows how to generate and throw a suitable BusinessRuleException if there were setter exceptions
• A helper for generating client-side validation code based on System.ComponentModel.DataAnnotations attributes (perhaps supporting multiple JS validation libraries)

How CSRF works

So, what’s it all about? All web application platforms are potentially vulnerable to CSRF, but in this post I’ll focus on ASP.NET MVC. Imagine you have a controller class as follows:

public class UserProfileController : Controller
{
    public ViewResult Edit() { return View(); }
 
    public ViewResult SubmitUpdate()
    {
        // Get the user's existing profile data (implementation omitted)
        ProfileData profile = GetLoggedInUserProfile();
 
        // Update the user object
        profile.EmailAddress = Request.Form["email"];
        profile.FavoriteHobby = Request.Form["hobby"];
        SaveUserProfile(profile);
 
        TempData["message"] = "Your profile was updated.";
        return View();
    }
}

This is all very normal. First, the visitor goes to Edit(), which renders some form to let them change their user profile details. Secondly, they post that form to SubmitUpdate(), which saves the changes to their profile record in the database. There’s no XSS vulnerability here. Everything’s fine, right? We implement this sort of thing all the time…

Unfortunately, this innocent controller is an easy target for CSRF. Imagine that an attacker sets up the following HTML page and hosts it on some server of their own:

<body onload="document.getElementById('fm1').submit()">
    <form id="fm1" action="http://yoursite/UserProfile/SubmitUpdate" method="post">
        <input name="email" value="hacker@somewhere.evil" />
        <input name="hobby" value="Defacing websites" />
    </form>
</body>

Next, they somehow persuade a victim to visit this page (basic social engineering, look it up). When this HTML page loads, it submits a valid form post to /UserProfile/SubmitUpdate on your server.

Assuming you’re using Windows authentication or some kind of cookie-based authentication system such as Forms Authentication, the automated form post will be processed within the victim’s established authentication context, and will successfully update the victim’s email address to something under the attacker’s control. All the attacker has to do now is use your “forgotten password” facility, and they’re taken control of the victim’s account.

Of course, instead of changing an victim’s email address, they can perform any action that the victim can perform with a single POST request. For example, they might be able to grant administrative permissions to another account, or post something defamatory to a CMS.

Ways to stop CSRF

There are two main ways to block CSRF:

• Check that incoming requests have a Referer header referencing your domain. This will stop requests unwittingly submitted from a third-party domain. However, some people disable their browser’s Referer header for privacy reasons, and attackers can sometimes spoof that header if the victim has certain versions of Adobe Flash installed. This is a weak solution.
• Put a user-specific token as a hidden field in legitimate forms, and check that the right value was submitted. If, for example, this token is the user’s password, then a third-party can’t forge a valid form post, because they don’t know each user’s password. However, don’t expose the user’s password this way: Instead, it’s better to use some random value (such as a GUID) which you’ve stored in the visitor’s Session collection or into a Cookie.

Using the AntiForgeryToken helpers

With Preview 5, Microsoft has added a set of helpers to the “futures” assembly, Microsoft.Web.Mvc.dll, that give you a means to detect and block CSRF using the “user-specific tokens” technique.

To use these helpers to protect a particular form, put an Html.AntiForgeryToken() into the form, e.g.,

<% using(Html.Form("UserProfile", "SubmitUpdate")) { %>
    <%= Html.AntiForgeryToken() %>
    <!-- rest of form goes here -->
<% } %>

This will output something like the following:

<form action="/UserProfile/SubmitUpdate" method="post">
    <input name="__MVC_AntiForgeryToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
    <!-- rest of form goes here -->
</form>

At the same time, Html.AntiForgeryToken() will give the visitor a cookie called __MVC_AntiForgeryToken, with the same value as the random hidden value shown above.

Next, to validate an incoming form post, add the [ValidateAntiForgeryToken] filter to your target action method. For example,

[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
    // ... etc
}

This is an authorization filter that checks that:

• The incoming request has a cookie called __MVC_AntiForgeryToken
• The incoming request has a Request.Form entry called __MVC_AntiForgeryToken
• These cookie and Request.Form values match

Assuming all is well, the request goes through as normal. But if not, boom!, there’s an authorization failure with message “A required anti-forgery token was not supplied or was invalid”.

This prevents CSRF because even if a potential victim has an __MVC_AntiForgeryToken cookie, an attacker can’t find out its value, so they can’t forge a valid form post with the same value in Request.Form. But legitimate users aren’t inconvenienced at all; the mechanism is totally silent.

Using salt

Salt? What? In case you want to protect multiple forms in your application independently of each other, you can use a “salt” value when you call Html.AntiForgeryToken(), e.g.,

<%= Html.AntiForgeryToken("someArbitraryString") %>

… and also in [ValidateAntiForgeryToken], e.g.,

[ValidateAntiForgeryToken(Salt="someArbitraryString")]
public ViewResult SubmitUpdate()
{
    // ... etc
}

Salt is just an arbitrary string. A different salt value means a different anti-forgery token will be generated. This means that even if an attacker manages to get hold of a valid token somehow, they can’t reuse it in other parts of the application where a different salt value is required. (If anyone can suggest other use cases for salt, please let me know.)

Limitations of the Anti-Forgery helpers

ASP.NET MVC’s anti-CSRF helpers work very nicely, but you should be aware of a few limitations:

• All legitimate visitors must accept cookies (otherwise, [ValidateAntiForgeryToken] will deny their form posts). Arguably this isn’t a limitation, because unless visitors allow cookies, you probably don’t have anything to protect anyway.
• It only works with POST requests, not GET requests. Arguably this isn’t a limitation, because under the normal HTTP conventions, you shouldn’t be using GET requests for anything other than read-only operations.
• It’s easily bypassed if you have any XSS holes on your domain. An XSS hole would allow an attacker to read a victim’s anti-forgery token value, then use it to forge valid posts. So, don’t have XSS holes!
• It relies on the potential victim’s browser implementing cross-domain boundaries solidly. Browsers are supposed to stop foreign domains from reading your app’s response text and cookies, and are supposed to stop foreign domains from writing cookies to your domain. If an attacker manages to find a way around this, they can bypass [ValidateAntiForgeryToken]. Of course that’s not supposed to be possible. For the most part, modern browsers block this line of attack.

In conclusion, ASP.NET MVC’s anti-CSRF helpers are easy to use, and work very nicely thank you!

These have been standard in web browsers since since 1558 AD, when the legendary Duke of Login first invented the idea of logging in. Respect!

Most web developers who want to do programmatic authentication (i.e., validating credentials against Forms Authentication or directly against a database) don’t use this native browser login prompt, for two reasons:

• It’s not clear how to make it work with programmatic authentication
• It’s believed to be insecure (for some reason)

First, I’ll show how to use the native login prompt programmatically with ASP.NET MVC, then we’ll talk about security.

A Quick Overview of the HTTP Basic Authentication Protocol

So, how does the native login prompt actually work? What makes it appear, and what data does it send from the browser to the server?

1. The browser makes a request to some URL
2. The server sends back a response with an HTTP status code of 401 (meaning “Not authorized”), plus a header describing the types of authentication it will accept. For example:
       WWW-Authenticate: Basic
3. This makes the browser display a login prompt, but it doesn’t display any other text that’s in the response. (It only displays that response text if the user clicks “Cancel”.)
4. When the user enters some credentials, the browser resubmits the same request to the same URL, plus it also adds this extra header:
       Authorization: Basic username:password
   Note that the username:password bit is actually Base-64 encoded.
5. The server parses the username and password from the request, and decides whether the credentials are valid or not. If they are valid, it lets the user continue (so it might return a proper HTML response, or it might redirect to somewhere else). If they are invalid, it returns a 401 again (i.e., goes back to step 2).
6. If the user enters the same incorrect credentials twice in a row, the browser normally won’t bother resubmitting them and will just give up.

Using HTTP Basic Authentication programmatically in ASP.NET MVC

Now you know how HTTP Basic authentication works, it’s easy to use it from ASP.NET MVC. Just follow the above script, playing the role of the server.

Let’s say you want to combine Forms Authentication with a browser-native login prompt. Start by setting up Forms Authentication, i.e., put into your web.config file:

<authentication mode="Forms">
  <forms loginUrl="~/Account/Login" defaultUrl="~/">
    <credentials passwordFormat="SHA1">
      <user name="admin" password="e9fe51f94eadabf54dbf2fbbd57188b9abee436e" />
    </credentials>
  </forms>
</authentication>

Note that e9fe51… is the SHA1 hash of “mysecret”, so this configuration has a single hard-coded login name, “admin”, with password “mysecret”. In a more realistic app you’d probably not have any <credentials> in your web.config, and instead set up a membership provider to store credentials in a database. But that doesn’t change the rest of this example.

Now, assuming you’ve decorated some controller or action method with [Authorize], when the user visits that controller or action, they’ll be redirected to ~/Account/Login. To handle that request, create a new controller class called AccountController, as follows. You can replace the default implementation of AccountController if you have one.

public class AccountController : Controller
{
    public void Login()
    {
        // Ensure there's a return URL
        if (Request.QueryString["ReturnUrl"] == null)
            Response.Redirect(FormsAuthentication.LoginUrl + "?ReturnUrl=" + Server.UrlEncode(FormsAuthentication.DefaultUrl));
 
        if (TempData.ContainsKey("allowLogin"))
        {
            // See if they've supplied credentials
            string authHeader = Request.Headers["Authorization"];
            if ((authHeader != null) && (authHeader.StartsWith("Basic")))
            {
                // Parse username and password out of the HTTP headers
                authHeader = authHeader.Substring("Basic".Length).Trim();
                byte[] authHeaderBytes = Convert.FromBase64String(authHeader);
                authHeader = Encoding.UTF7.GetString(authHeaderBytes);
                string userName = authHeader.Split(':')[0];
                string password = authHeader.Split(':')[1];
 
                // Validate login attempt
                if (FormsAuthentication.Authenticate(userName, password))
                {
                    FormsAuthentication.RedirectFromLoginPage(userName, false);
                    return;
                }
            }
        }
 
        // Force the browser to pop up the login prompt
        Response.StatusCode = 401;
        Response.AppendHeader("WWW-Authenticate", "Basic");
        TempData["allowLogin"] = true;
 
        // This gets shown if they click "Cancel" to the login prompt
        Response.Write("You must log in to access this URL.");
    }
}

(By the way, I’m fully aware that the Login() action eschews a number of ASP.NET MVC best practices - it doesn’t return a useful ActionResult, and it calls Response.Redirect() directly. This makes it unsuitable for unit testing. I did this because fundamentally it’s using the static and hard-to-test FormsAuthentication API anyway. You can wrap all the static method calls inside an interface and use constructor injection, and perhaps return some special HttpBasicActionResult, if you want to make it testable - but I didn’t want to distract from the real point of this example.)

That does it! Now when a visitor goes to anything protected with [Authorize], they’ll get a browser-native login prompt, such as the one shown below. If the visitor enters valid credentials (i.e., admin/mysecret), then they’ll be given a Forms Authentication cookie, and will be redirected back to the action method they requested.

Notice in this screenshot that IE gives a warning about “basic authentication without a secure connection“. We’ll talk about secure connections (SSL) in a moment.

Next, you’ll want to give visitors some way of logging out. This has nothing to do with HTTP basic authentication; it’s just a matter of revoking the visitor’s Forms Authentication cookie. So, add this to AccountController:

public RedirectResult Logout()
{
    FormsAuthentication.SignOut();
    return Redirect(FormsAuthentication.DefaultUrl);
}

What a very simple way of getting a nice login UI.

Is this secure?

HTTP Basic authentication has an undeserved reputation for being insecure. Yes, it does send credentials over the wire in plain text (well, Base-64 encoded, but that’s basically the same). But then if you make a custom login form (such as the one in the default ASP.NET MVC project template), that sends credentials in plain text too. The level of security is identical.

Either way, you must protect the transmission by doing it over SSL. And that’s just as easy, or difficult, whether you use the browser’s native login prompt or create your own custom login screen.

One quirk of HTTP basic authentication is that the browser keeps on sending the Authorization header with every request that appears to be in the same folder as the one where it was originally requested. So, in this example, the browser will keep sending the Authorization header with every request to AccountController (but not to other controllers). That means you shouldn’t let the browser perform any requests to AccountController that aren’t wrapped in SSL. Also, HTTP basic authentication doesn’t give any natural way to log out, which is why I added the TempData[”allowLogin”] test so that you always get a login prompt the first time you go to Login(). When a visitor clicks “log out”, it does erase their Forms Authentication cookie, but the browser still has the credentials in its HTTP Basic cache. The user acts as logged out, but the credentials are still in the browser’s memory until they close the browser.

Conclusion

Using ASP.NET MVC, it’s easy to make a browser pop open its native login prompt, and to parse out the credentials that a user enters. These login credentials are no more or less secure than credentials entered into a normal custom login form.

However, it’s also easy to create a custom login form. This gives you more control over its appearance, and avoids the quirks of HTTP basic authentication with regard to logging out. Therefore, for most applications, it’s usually best still to create a custom login form.

This article was expanded from a short example that I was originally going to put in my forthcoming ASP.NET MVC book, but I decided to remove it from the book because it isn’t quite worthy enough…