Combining HttpPost and ValidateAntiForgeryToken

Thursday, September 8, 2016 by K. Scott Allen

I’ve been kicking around the idea of combining [HttpPost] and [ValidateAntiForgeryToken] in an application using authentication cookies. Both attributes typically appear together to prevent cross-site request forgeries in MVC applications using cookie based authentication. The result looks like the following.

public IActionResult Edit(Input model)
    // ... 

And the attribute definition is as follows.

public class HttpPostWithValidAntiForgeryToken
    : Attribute, IActionHttpMethodProvider, IFilterFactory
    private readonly HttpPostAttribute _postAttribute;
    private readonly ValidateAntiForgeryTokenAttribute _antiForgeryAttribute;

    public HttpPostWithValidAntiForgeryToken()
        _postAttribute = new HttpPostAttribute();
        _antiForgeryAttribute = new ValidateAntiForgeryTokenAttribute();

    public IEnumerable<string> HttpMethods => _postAttribute.HttpMethods;

    public IFilterMetadata CreateInstance(IServiceProvider serviceProvider)
        return _antiForgeryAttribute.CreateInstance(serviceProvider);

    public bool IsReusable => _antiForgeryAttribute.IsReusable;

With the new attribute, a plain [HttpPost] should never appear in the application, and a unit test using reflection could enforce the rule.

Don't Throw Away All Those web.config Settings

Tuesday, September 6, 2016 by K. Scott Allen

ASP.NET Core might not use a complicated hierarchy of XML configuration files anymore, but if you host under IIS, then IIS and web.config are still the best of friends. There is some XML configuration required to run Core under IIS, specifically the part to reverse proxy all incoming requests over to the ASP.NET Core module and ultimately into the Kestrel server.

Other pieces of web.config still work in the new world of ASP.NET, too. For example, IIS will still honor rewrite rules in web.config.

Here is a sample web.config to enforce lower case URLs that also proxies to the ASP.NET Core Module.

<?xml version="1.0" encoding="utf-8"?>

        <rule name="Convert to lower case" stopProcessing="true">
          <match url=".*[A-Z].*" ignoreCase="false" />
          <action type="Redirect" url="{ToLower:{R:0}}" redirectType="Permanent" />
      <add name="aspNetCore" path="*" verb="*" 
           modules="AspNetCoreModule" resourceType="Unspecified"/>
    <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" 
                stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" 

The Troubles with JavaScript Arrow Functions

Thursday, September 1, 2016 by K. Scott Allen

Over the summer I gave a talk titled “The New Dragons of JavaScript”. The idea was to provide, like the cartographers of the Old World, a map of where the dragons and sea serpents live in the new JavaScript feature landscape. These mythological beasts have a tendency to introduce confusion or pain in software development.

Arrow functions have surprised me with the amount of turmoil they’ve created. At first glance, they seem so easy, like when multiplying the numbers in an array by 2.

const numbers = [1, 2, 3];
const result = => n * 2);
// produces [2,4,6]

But even a simple map operation can run into problems if the code tries to map each element to an object literal using the wrong syntax.

const numbers = [1, 2, 3];
const result = => { value: n });
// produces [undefined], [undefined], [undefined]

The problem in the above code is that the opening curly brace of the arrow function makes JavaScript think there is a block of code to execute instead of a simple object literal expression to evaluate. The result is an array of undefined. In this scenario the code either needs an explicit return statement, or to parenthesize the object literal.

const result = => ({ value: n }));
// [{value: 1}, {value:2}, {value:3}]

Ironically, most problems developers encounter with arrow functions center around the problem arrow functions attempt to solve. The slippery JavaScript this pointer. A bit of casual reading about arrow functions will tell you how arrow functions capture the this reference from their lexical environment. With arrows, you can write code like the following without worrying about explicitly capturing this into a local variable.

const adder = {
    sum: 0,
    add(numbers) {
        numbers.forEach(n => {
            this.sum += n;


adder.add([1, 2, 3]);
// adder.sum === 6

However, it’s easy to write code that assumes the wrong environment. In the following code we have an arrow function inside an arrow function, so the this reference will not be the adder object, but whatever scope the adder object lives in.

const adder = {
    sum: 0,
    add: (numbers) => { // scope here is important
        numbers.forEach(n => {
            this.sum += n;


adder.add([1, 2, 3]);
// adder.sum === 0

The biggest sea dragon on the map in the arrow function waters is highlighted in the “NOTE” section of 14.2.16 of the spec. The takeaway here is that we cannot change the this reference inside of an arrow function. The reference is fixed, it’s baked, it’s  static and permanent. There are implications for two types of code. First is the type of code that expects to manipulate this using bind, call, or apply.

const adder = {
    sum: 0

const add = (numbers) => numbers.forEach(n => this.sum += 1);

adder.add = add.bind(adder);

adder.add([1, 2, 3]);
// adder.sum === 0

The second type of code is code that expects someone else to setup this for a call. I first experienced the brain teaser of unexpected this values writing arrow functions with Jasmine. Jasmine sets this to a context object for sharing state between test setups and asserts. Arrow functions, Jasmine contexts and regular functions mix into a broken cocktail. The same problem can arise with DOM event handlers.

it("this is not what you might expect", () => {

    // .. this?



Arrow functions are not a replacement for regular functions in JavaScript. There are situations where arrow functions do not work as expected. I’m not giving up on arrow functions, I still use them when possible. However, I do lament the fact that I still need to fret over every use of this in JavaScript code.

Keeping a Clean Startup.cs in Asp.Net Core

Tuesday, August 30, 2016 by K. Scott Allen

In some applications the Configure and ConfigureServices methods of Startup.cs can become unwieldy. It’s not complicated logic, but with all the middleware and services and options to configure, the methods become long and messy.

I prefer to keep a series of simple, one-line method calls inside of both methods.

public void ConfigureServices(IServiceCollection services)
    // ...
    // ...

All of the details for these method calls live inside extensions methods for IApplicationBuilder or IServiceCollection. Here’s an example. 

public static class ServiceCollectionExtensions
    public static IServiceCollection AddCustomizedMvc(this IServiceCollection services)
        var locationFormat = @"Features\Shared\{0}.cshtml";
        var expander = new ViewWithControllerViewLocationExpander();

           .AddRazorOptions(options =>

        return services;

    // ...

The New LINQ Fundamentals

Wednesday, August 17, 2016 by K. Scott Allen

The first course I ever made for Pluralsight was a LINQ Fundamentals course in 2008. I’ve received many great bits of feedback about the course over the last 8 years, but I’ve also learned a few things about teaching, presenting, and making courses during that time, too. Whenever I’m forced to listen to a clip from this early course I cringe. I sound like my speech was addled by sleeping pills and vodka.

A few months ago I decided it was time to make a new LINQ Fundamentals course, and this course was released just a few weeks ago. It’s mostly the same material as the original course, but with a more logical story arc and a perky sounding instructor.

I hope you enjoy watching the videos!


LINQ Fundamentals Training

Stop Running with the Visual Studio Debugger

Tuesday, August 16, 2016 by K. Scott Allen

A number of people who have seen me code this year have asked me how I can make changes in an ASP.NET web application and see the changes in the browser without restarting the web application. The person asking always runs the application by starting the Visual Studio debugger.

The problem with starting the debugger is that later you’ll have to stop the debugger, and stopping the debugger also stops the default host process (IIS Express). Refreshing the browser at this point is like waiting for an echo in the emptiness of space.

No server is available to respond!



I always run web applications without the debugger. The default shortcut key for this behavior is Ctrl + F5. Now the server can stay up and running, and changes are automatically loaded and seen in the browser after a reload. I will only run with the debugger if I have to debug code.

Unfortunately, Visual Studio encourages us to run with the debugger. Not only is the shortcut key easier (just F5), running with the debugger is also featured prominently in the menus and toolbars that appear in a web project.


Do yourself a favor and use Ctrl+F5 instead!

Dynamically Add Routes in Aurelia

Tuesday, May 31, 2016 by K. Scott Allen

Routes are usually defined in an Aurelia application using a model’s configureRouter method in a declarative manner.

configureRouter(config, router) {
    this.router = router; 
    config.title = "The App";[
        { route: "", name: 'home', moduleId: "app/home", 
          title:"Home", nav:true
        { route: "about", moduleId: "app/about", 
          title: "About", nav:true 

However, you can also add routes at anytime using the Router’s API.

constructor(router) {
    this.router = router; 

addRoute() {
         { route: "secret", name: 'secret', moduleId: "app/secret", 
           title:"Secret", nav:true 

I’d stick with the declarative routing whenever possible, but dynamically adding routes is useful in a few scenarios.

My Pluralsight Courses

K.Scott Allen OdeToCode by K. Scott Allen
What JavaScript Developers Should Know About ECMAScript 2015
The Podcast!