Time to create a new build and deploy it to the DEV environment, right? Well...

While testing in the DEV environment, everything still worked except when we hit that RedirectToAction flow: the session state was being reset every time! I doublechecked all of the settings, but didn't see any obvious issues there. Then I tried to use TempData as a fallback for the RedirectToAction flow, which fixed the issue on the remote environment.

Huh. But TempData, just like Session, also uses cookies... Why does TempData work then when Session doesn't? Is it a difference in implementation, or the positioning of the middleware?

TempData, by default, uses its own cookie. You can also specify this behavior manually or change the cookie settings by calling AddCookieTempDataProvider:

services.AddControllersWithViews()
    .AddCookieTempDataProvider();

You can also tell ASP.NET Core that you want TempData to use Session if you're already using Session anyway, to reduce the amount of cookies used and to rely on the distributed cache when running your web application on multiple machines. To do this, simply replace the AddCookieTempDataProvider call with AddSessionStateTempDataProvider. You don't (or can't) provide any configuration to this method, because the configuration is being done when adding session support:

services.AddControllersWithViews()
    .AddSessionStateTempDataProvider();

services.AddSession(x =>
{
    x.Cookie.HttpOnly = true;
    x.Cookie.SecurePolicy = CookieSecurePolicy.Always;
    x.Cookie.SameSite = SameSiteMode.Strict;
    x.Cookie.Name = Configuration["CookieNames:Session"];
});

This is how we configured the session's cookie:

• HTTP Only, because we don't want any JavaScript to access the session cookie
• SecurePolicy set to Always, because we use HTTPS all the way
• SameSite set to Strict, because we don't want this cookie to be sent when a request is initiated by a third-party
• And finally, we change the name to be something less obvious.

Because TempData worked, and we already had Session enabled, I tried using the SessionStateTempDataProvider. Guess what? TempData stopped working between redirects.

Back to the investigation. What's the difference between using session to store TempData and using the original CookieTempDataProvider? Well, here's the source code of CookieTempDataProviderOptions :

// Licensed to the .NET Foundation under one or more agreements.
// The .NET Foundation licenses this file to you under the MIT license.

using System;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc.ViewFeatures;

namespace Microsoft.AspNetCore.Mvc;

/// <summary>
/// Provides programmatic configuration for cookies set by <see cref="CookieTempDataProvider"/>
/// </summary>
public class CookieTempDataProviderOptions
{
    private CookieBuilder _cookieBuilder = new CookieBuilder
    {
        Name = CookieTempDataProvider.CookieName,
        HttpOnly = true,

        // Check the comment on CookieBuilder below for more details
        SameSite = SameSiteMode.Lax,

        // This cookie has been marked as non-essential because a user could use the SessionStateTempDataProvider,
        // which is more common in production scenarios. Check the comment on CookieBuilder below
        // for more information.
        IsEssential = false,

        // Some browsers do not allow non-secure endpoints to set cookies with a 'secure' flag or overwrite cookies
        // whose 'secure' flag is set (http://httpwg.org/http-extensions/draft-ietf-httpbis-cookie-alone.html).
        // Since mixing secure and non-secure endpoints is a common scenario in applications, we are relaxing the
        // restriction on secure policy on some cookies by setting to 'None'. Cookies related to authentication or
        // authorization use a stronger policy than 'None'.
        SecurePolicy = CookieSecurePolicy.None,
    };

    /// <summary>
    /// <para>
    /// Determines the settings used to create the cookie in <see cref="CookieTempDataProvider"/>.
    /// </para>
    /// <para>
    /// <see cref="CookieBuilder.SameSite"/> defaults to <see cref="SameSiteMode.Lax"/>. Setting this to
    /// <see cref="SameSiteMode.Strict"/> may cause browsers to not send back the cookie to the server in an
    /// OAuth login flow.
    /// <see cref="CookieBuilder.SecurePolicy"/> defaults to <see cref="CookieSecurePolicy.SameAsRequest" />.
    /// <see cref="CookieBuilder.HttpOnly"/> defaults to <c>true</c>.
    /// <see cref="CookieBuilder.IsEssential"/> defaults to <c>false</c>, This property is only considered when a
    /// user opts into the CookiePolicyMiddleware. If you are using this middleware and want to use
    /// <see cref="CookieTempDataProvider"/>, then either set this property to <c>true</c> or
    /// request user consent for non-essential cookies.
    /// </para>
    /// </summary>
    public CookieBuilder Cookie
    {
        get => _cookieBuilder;
        set => _cookieBuilder = value ?? throw new ArgumentNullException(nameof(value));
    }
}

Did you spot it? Apparently, there's a bug in browsers (yes, I call this a bug), that causes browsers to not send a cookie back to the server in OAuth login flows when the SameSite is set to Strict. And during OAuth login flows, a lot of redirects occur.

With this new knowledge, I tried relaxing the settings of the session cookie by setting x.Cookie.SameSite = SameSiteMode.Lax; and deployed this attempt to the server.

It worked! TempData survived the redirect, together with the Session!

So, should you find yourself in a situation where something cookie-related works locally but not remotely, and that cookie uses SameSiteMode.Strict? Then first try to relax it a little before trying anything else.

v1

We want to wrap HTTP responses into something like Response<T>. But, you know, the web is finicky and sometimes stuff breaks somewhere, so we might get a 4xx or 5xx response back. We need to represent these cases as well.

So, without further ado, here is version 1:

public class Response<T>
{
    public Response(T value)
    {
        Value = value;
        IsError = false;
    }

    public Response(string error)
    {
        Error = error;
        IsError = true;
    }

    public T Value { get; }
    public string Error { get; }
    public bool IsError { get; }
}

As Ken already mentioned in his post: what if T is a string? The only way in that case to specify the correct constructor, is by using named parameters:

var valueResponse = new Response<string>(value: "text");

This is too confusing for any developer in my opinion: the differentiation between a successful response and an erroneous one is completely lost.

v2

First of all, let's introduce contracts rather than classes to model the success and error responses. These make it easier to introduce tests in the system and allow for extensibility.

public interface IResponse<out T>
{
    int StatusCode { get; }
    T Value { get; }
}

public interface IErrorResponse<out T> : IResponse<T> 
{
    string Error { get; }
    string OriginalData { get; }
    Exception Exception { get; }
    bool HasException { get; }
}

In case you're wondering why I opted for an int instead of System.Net.HttpStatusCode for the property StatusCode: not all status code possibilities exist in the enum, like 429 - Too Many Requests. But don't worry, the implementation will allow you to pass in HttpStatusCode's as well.

Let's now implement a class so we can return successful responses from an HTTP service:

public class Response<T> : IResponse<T> 
{
    internal Response(HttpStatusCode statusCode, T value)
        : this((int)statusCode, value)
    {
    }

    internal Response(int statusCode, T value)
    {
        StatusCode = statusCode;
        Value = value;
    }

    public int StatusCode { get; }
    public T Value { get; }
}

And for an error response:

public class ErrorResponse<T> : IErrorResponse<T>
{
    internal ErrorResponse(HttpStatusCode statusCode, string error)
        : this((int)statusCode, error)
    {
    }

    internal ErrorResponse(int statusCode, string error)
    {
        StatusCode = statusCode;
        Error = error;
    }

    public int StatusCode { get; }
    public string Error { get; }

    public string OriginalData { get; internal set; }
    public Exception Exception { get; internal set; }
    public bool HasException => Exception != null;

    T IResponse<T>.Value => default; // Needs C# 7.1
}

That last line will hide the Value property - which is only interesting when the response was successfull anyway - when you are working with an instance of a class that implements IErrorResponse<T>. It will however still show up when you cast to the interface(s), but will be either null or the default value for a value type. Note that you could still write default(T), C# 7.1 just provides a slightly shorter way.

Bringing success and error together: the HTTP service

When retrieving data from an HTTP service, we will either return a Response<T> when everything's OK (2xx response) and the data we get back can actually be converted back to what we expect to find (something T-ish). If anything else happens, we will return an ErrorResponse<T> instead, containing as much data as we can supply to the caller.

protected async Task<IResponse<T>> Get<T>(string uri) 
{
    HttpResponseMessage response = null;
    string content = null;

    try
    {
        response = await Client.GetAsync(uri)
            .ConfigureAwait(false); // Client is a static System.Net.HttpClient instance

        content = await response.Content.ReadAsStringAsync()
            .ConfigureAwait(false);

        return response.IsSuccessStatusCode ? 
            CreateResponse<T>(response.StatusCode, content) : 
            CreateErrorResponse<T>(response.StatusCode, response.ReasonPhrase, originalData: content);
    }
    catch (Exception e)
    {
        return CreateErrorResponse<T>(
            response?.StatusCode ?? HttpStatusCode.InternalServerError, 
            e.Message, 
            e,
            content);
    }
}

private IResponse<T> CreateResponse<T>(HttpStatusCode statusCode, string json)
{
    try
    {
        var data = JsonConvert.DeserializeObject<T>(json);
        return new Response<T>(statusCode, data);
    }
    catch (Exception e)
    {
        return new ErrorResponse<T>(statusCode, "Couldn't deserialize the received data to the requested type.")
        {
            OriginalData = json,
            Exception = e
        };
    }
}

private IResponse<T> CreateErrorResponse<T>(
    HttpStatusCode statusCode, 
    string error, 
    Exception exception = null, 
    string originalData = null)
{
    return new ErrorResponse<T>(statusCode, error)
    {
        Exception = exception,
        OriginalData = originalData
    };
}

The majority of the Get<T> method should be familiar if you've ever called HTTP services using an HttpClient instance:

• We perform a GET /uri and await the response
• We read the returned data as a string. This contains either the actual data (2xx) or information (4xx, 5xx) about what went wrong.
• Using response.IsSuccessStatusCode, we check for 2xx responses. If the response was good, we call CreateResponse<T>. If not, we use CreateErrorResponse<T>.
• In the exception handler, we call CreateErrorResponse<T> to provide an error response including the exception details.

Inside the CreateResponse<T> method, we only need to keep in mind that the returned data might not be what we expect it to be, that is something that can be converted into a T. So when that happens, we catch the deserialization exception, and return an ErrorResponse<T> instead. I also need to mention that, in the full sample source code, I've set a default Accept header to only accept JSON from the HTTP service. It would be rather strange to call JsonConvert.DeserializeObject<T> with XML, right?

Update

I used to call response.EnsureSuccessStatusCode() to prevent having to call CreateErrorResponse<T> twice (and that used to be a new ErrorResponse<T> line instead), but that would raise an unnecessary exception and return false information, because there wasn't really an exception to begin with. We just faked one for our convenience. As Nico Vermeir pointed out, not causing an exception here is far more elegant.

Inspecting the result

We now have a way to represent success and error responses, and an HTTP service to get both of these. How can we now call that service and test if we have an error or not?

In the sample, I've provided a dummy CustomerService that uses the HttpService class:

public class CustomerService : HttpService
{
    public Task<IResponse<Customer>> GetCustomerById(int id)
    {
        return Get<Customer>($"https://api.myapp.local/customers/{id}");
    }
}

When we call that service, we can inspect the response:

var client = new CustomerService();
var response = await client.GetCustomerById(404);
if (response is IErrorResponse<Customer> error)
{
    Console.ForegroundColor = ConsoleColor.DarkRed;
    Console.WriteLine($"{error.StatusCode} - {error.Error}");
    if (error.HasException)
    {
        Console.WriteLine(error.Exception);
    }

    Console.ResetColor();

    return;
}

Console.WriteLine(response.Value);

Using a C# 7.0 feature, pattern matching, we can easily check if response is in fact an IErrorResponse<Customer>, rather than a successful response. If it is, the error instance is immediately available inside the if-block.

If the call to GetCustomerById worked just fine, we can access response.Value just like we would expect.

Wrapping it up

So, instead of dealing with both success and error in one class, I've provided two separate contracts to model them. Because IErrorResponse<T> implements IResponse<T>, we can use the latter as our base return type for all HTTP related methods. And thanks to pattern matching, it is now easier than ever to quickly check if the returned response is in fact an error.

Full sample code can be found on GitHub. Improvements and further discussions are welcome!

Now, before you think to skip this post because you've been programming for some years, I do suggest to glance over this post: you might see something you didn't know, or didn't see the benefit of that debugger feature. If you already knew everything I've written in this post, then you are awesome! And should you know a neat trick which I didn't cover, then don't hesitate to leave a comment :)

Let's start with the basics, shall we?

Stop! Hammer Time!

When you debug code to find out where exactly things are going wrong, you'll probably have an idea where to start searching in the code base:

• You just wrote some new classes/methods and things started behaving not quite as expected.
• A unit test fails suddenly.
• An exception has been thrown and you can see where it originates using the stack trace.

So, you have an idea where to start digging. The obvious thing to do then, is to tell the debugger to stop running the code at that point in the source. This is a breakpoint, which you can set using the Debug > Toggle Breakpoint menu item or its default shortcut key F9. Visual Studio, and many other IDE's, typically indicates a breakpoint with a red circle in front of the line of code, optionally also changing the colorization of the code:

When we run this code, Visual Studio will stop executing the application right before executing the line of code were we added the breakpoint. You will also see a yellow arrow pointing at that line. Think of the yellow arrow as the instruction pointer (or program counter) for your code:

At this moment, you can start inspecting your application state using the different windows provided by Visual Studio. These are the first few views which can be useful when debugging, and all of these can be found in the menu Debug > Windows while the debugger is active:

• Watch: you can have four different watch views. These views allow you to inspect variables, fields, properties, collections, methods, and so on. You'll see the value and the data type listed next to the watch entry.
• Autos: this is a special watch window, showing the result of the current and previous lines of code if it can.
• Locals: this is also a special watch window, displaying all variables and method parameters in the current method or lambda expression. However, it doesn't show properties or fields who are being referenced in that method or lambda expression.
• Call Stack: this window shows the execution path up until now per executed method. Because not all of the code is managed code (written using the .NET CLR), or when you are missing debug symbols, you'll see some entries appearing as [External Code]: this can either be a 3rd party library you're using but Visual Studio couldn't find the (correct) debug symbols or PDB files for that library, or it could be unmanaged code - things Windows needs to do to start your .NET application, creating an AppDomain for instance. We'll cover the Call Stack window later in this post more in depth.

In this code example, you've obviously already seen what will go wrong: as awesome a number 42 might be, dividing it by zero just doesn't work in this universe. Before evaluating the next line of code however, you can inspect what would happen by adding value / 0 in the Watch 1 window, either by selecting the statement, right-clicking it and select the Add Watch menu item, or by pasting/typing the statement in a row in the Watch window:

You can now stop the debugger (Debug > Stop Debugging, SHIFT+F5 or the Stop Debugging button in the toolbar) to fix the bad code, or you can even change it while the debugger is active:

Stop! When it's hammer time!

This is, however, the absolute basics of debugging. We can do better than this! One improvement lies in controlling when the debugger actually decides to stop when it arrives at a breakpoint. You can disable any breakpoint, without removing it, by hovering over it and pressing the disable button. Other options are to right-click and select Disable Breakpoint or to press the default shortcut Ctrl+F9. This is an easy way of controlling a method where the application passes through several times, but where you don't want to stop continuously. But it's not ideal, and we have better tools in our toolbox.

A second tool, is to enable breakpoint conditions. Breakpoint conditions allows us to only break when certain things are true:

• When value equals 42, this is a conditional expression.
• When we hit this breakpoint for the n-th time, this is a hit count expression.
• When we run this code on a certain machine, in a certain process or thread: a filter.

To get to these options, you can hover over the breakpoint and click the cog wheel icon (labeled Settings...) or right-click and select the Conditions... menu item.

Visual Studio will now only stop running our application when the value of divisor equals 0. Neat!

As you can see in the image above, we can also add Actions to a breakpoint: for example, to log information to the Output window every time we pass the breakpoint. Ironically, this is how I used to debug when I started out coding: putting PRINT statements all over the place, displaying the values of variables to know what was going on.

Stop! HammerNotFoundException!

Another nifty trick to know, especially when having to fix a hot issue in an unknown code base, is by setting breakpoints on (un)handled exceptions. In the example I've been using, I can declare - inside Visual Studio - that I want the debugger to break whenever the DivideByZeroException is being thrown for example, even if this exceptions has been caught in the code. This enables you to stop executing the application when an exception arises, instead of when it might get rethrown in a main thread. You can reach these awesome bits in the Exception Settings window, through the Debug > Windows > Exception Settings menu item or its default shortcut CTRL+ALT+E:

By default, you can choose to break on all unlisted exceptions, to break on your own exception types or those used by 3rd party libraries. That possibility is immediately followed by an extensive list of default exception types provided in the CLR, like the well-known System.NullReferenceException. You can also add specific missing exception types, by selecting the line Common Language Runtime Exceptions and hitting the Add button (indicated with the plus sign). When you right-click on an exception, you can choose an additional option: Continue when unhandled in user code. When you activate this, the debugger will not stop on that exception in your codebase if the exception is handled by the consumer of your code.

The Call Stack

I did promise a bit about the Call Stack window, didn't I? Well, here goes! Whenever the debugger stops running your application, the Call Stack window will show you the list of actions/methods/etc. that led up to the current point of execution:

Now, the [External Code] section is where things could get interesting. Basically, this is anything that is not in your code base, like native Windows API's, .NET CLR stuff, 3rd party libraries: you name it. You can however opt in to see what's behind the covers, by right clicking in the Call Stack window and enabling the option called Show External Code:

When you double click on an entry shown in black in the Call Stack (or right click and choose Switch to Frame), you can jump back and forth through the Call Stack, inspecting the flow of your application up to where it was interrupted by - for example - a breakpoint, including the state of each frame. This means that you can inspect all variables and fields for each step in the Call Stack, which can give you a lot more insight when trying to pinpoint where things might've gone wrong:

Now, you can also try to do this for code outside your code base, displayed as gray entries. Try clicking on a gray line in the Call Stack, and you'll be presented a window looking somewhat like this, depending on your settings:

Basically, Visual Studio is telling you that it can't display any source code for the frame you've selected to inspect, but it can try to load debug symbols (or PDB files) which will help in showing some degree of information. As a last resort, you can try to click the View disassembly link, which will show you what's going on at the most basic of levels. You can, of course, add your own symbol servers. This can be convenient when you have a custom package feed with its own debug symbol source, or when you want to build debug symbols on the fly using DotPeek for example. Check out these two links to learn more about these possibilities, they will definitely help you when dealing with strange behavior in 3rd party libraries!

There are much more features hidden inside the Debug menu, but I'm going to save these for another post, where we will dive into more advanced concepts. Stay tuned!

Together with Maarten (who already has written some content concerning debugging and monitoring software), we're going to write some posts about the concept of debugging code. And to introduce the topic, why not start with a little bit of (mostly personal) history on the matter?

ENIAC

It's hard to imagine nowadays, but writing software wasn't always literally writing: on the ENIAC i.e., the programmers had to make physical connections between the different components, replacing burnt out vacuum tubes as they progressed. They did actually write the program on paper first though, and did their very best to run through it step by step before starting to program the actual computer. And even then, they went through the program again: even the ENIAC already supported step-through debugging!

My First Program and QBASIC

When I was in the Sixth grade, at the age of eleven, I got the chance to learn to program in QBASIC on a 386 PC, running MS-DOS 6.0, during breaks. Well, that and the occasional Sega OutRun game. But programming really caught my interest and I quickly went through the assignments my teacher had created. Meanwhile, we got a PC at home, so I could continue learning to program. In the end, I'd written several game clones like Breakout, Tetris, etc.

My programming skills, however, were quite limited: it took me a while to figure out that I could use subroutines (GOSUB) instead of line numbers and the now dreaded GOTO. And as far as debugging was concerned, I was using the oldest trick in the book: a lot of PRINT statements to know the value of certain variables at specific steps in the code. I'm not kidding when I say that I only recently found out that QBASIC supported step-through debugging and setting breakpoints in code: nobody told me these things when I started programming and I didn't know English well enough to figure this out myself.

Moral of the story so far: you will learn to appreciate any help the debugger tools provide once you had to resort to printing variable values.

Windows 3.11 and Visual Basic 4.0

As I got older, I stumbled upon VB4 which allowed me to create software with Forms. My own Windows in Windows! And because I started getting English class at school, I also understood more about the options I had to create software. Finally I discovered things like breakpoints, watches, step-through debugging and Visual Basics way of error handling. Aside from games, I could also start writing more useful software for family and friends.
The summum? Writing a new UI which emulated the Windows 95 look and feel to convince my dad to upgrade the PC (it needed 8 megs of RAM instead of 4) and to buy that shiny Windows 95 upgrade.

VB6, C/C++, PHP, ...

I also upgraded to Visual Basic 97, then 6.0, started to dabble in C/C++ and wrote my first web applications in PHP. That was a step back in time really. Sure, you could run a WAMP server locally to test your code, but you couldn't attach a debugger to that server to debug the code as you went through the application (I'm talking about PHP3/4 here, way before the Zend era). So instead, I had to rely on echoing stuff back into my web pages or logging it and looking at the log files. Or even worse, stop the code from processing at all using die() statements, which typically happened when you couldn't connect to the MySQL database.

Maybe we are spoiled today, with the capabilities offered by the different debugger tools available. But then again, are we using them efficiently? Find out in my next post in this series!

But I'm not going to focus on SQL Injection here, I'm going to take it one step further. If you want to read up on SQL Injection, Bing/Google is your friend. Or just take a look at good old Bobby Tables.

People often think: "It's called SQL Injection, but I'm not using SQL here, so I'm safe."

Wrong.

From the moment you're using any type of query or filtering language construct, you can introduce some form of SQL Injection in your code:

• Using (n)Hibernate with HQL? Are you using parameters in those queries or not?
• You're using Azure Table Storage or another NoSQL DB. But does NoSQL mean No SQL Injection?

Another fun example uses the System.Linq.Dynamic NuGet package. This little gem allows you to use string expressions to filter on IEnumerable's. And because it makes our developer life easier, we could use this to filter data in a Web API, for example. Take a look at this piece of code:

public async Task<IEnumerable<User>> GetUsersAsync(string filter)
{
    // Lets say the current user can only access data with odd ID's
    var fullFilter = "(id % 2) = 1";

    if (!string.IsNullOrEmpty(filter))
    {
        fullFilter += $" && {filter}";
    }

    return (await DbContext.Users.ToListAsync()).Where(fullFilter);
}

Yes, I know this is not the best code because you're fetching all users from the database and then you reduce the result set, but bear with me. I'm making a statement here. Besides, this kind of code is still being written in production as well!

As you can see, you're applying a filter to a list of User instances using System.Linq.Dynamic. That filter could be, for example, this:

"name.StartsWith(\"n\")"

This would reduce the results down to all users with an odd ID and where the surname starts with "n". But someone could circumvent our fixed "odd ID" filter part, which would ignore our little security measure, by changing the filter a bit:

1 = 1 || 1 = 1

This filter value would make fullFilter look like this:

(id % 2) = 1 && 1 = 1 || 1 = 1

Because we're missing parentheses around the user filter part, the ID filter will be ignored. One solution could be to add these parentheses.

public async Task<IEnumerable<User>> GetUsersAsync(string filter)
{
    // Lets say the current user can only access data with odd ID's
    var fullFilter = "(id % 2) = 1";

    if (!string.IsNullOrEmpty(filter))
    {
        fullFilter += $" && ({filter})";
    }

    return (await DbContext.Users.ToListAsync()).Where(fullFilter);
}

Actually, you could solve that problem by moving the fixed filter part. That way, no matter what your user is requesting, he or she can't get by the fixed filter anymore:

public async Task<IEnumerable<User>> GetUsersAsync(string filter)
{
   // Lets say the current user can only access data with odd ID's
   var query = DbContext.Users.Where(x => x.Id % 2 == 1);

   if (!string.IsNullOrEmpty(filter))
   {
      return (await query.ToListAsync()).Where(filter);
   }

   return await query.ToListAsync();
}

And to complete the story, you can look at using parameterized queries, which is also supported by System.Linq.Dynamic. Using parameters in your filter would take away some of the filtering power from the consumer of your API, but you could reintroduce that power by defining your own filters. This example shows a basic attempt at implementing this:

public async Task<IEnumerable<User>> GetUsersAsync(string filter)
{
    // Lets say the current user can only access data with odd ID's
    var query = DbContext.Users.Where(x => x.Id % 2 == 1);

    if (!string.IsNullOrEmpty(filter))
    {
        var parsed = ParseFilter(filter);
        return (await query.ToListAsync()).Where(parsed.Filter, parsed.ParamList.ToArray());
    }

    return await query.ToListAsync();
}

private ParsedFilter ParseFilter(string filter)
{
    var newFilter = new StringBuilder(filter.Length);
    var paramList = new List<object>();

    var filterParts = filter.Split(new[] { ' ' }, StringSplitOptions.RemoveEmptyEntries);
    var i = 0;
    var paramIndex = 0;

    while (i < filterParts.Length)
    {
        string @operator = "", property = "";
        object literal = null;
        var parts = new[] {filterParts[i++], filterParts[i++], filterParts[i++]};

        foreach (var part in parts)
        {
            if (IsStringLiteral(part))
            {
                literal = part.Substring(1, part.Length - 2);
                continue;
            }

            if (IsBoolLiteral(part))
            {
                literal = bool.Parse(part);
                continue;
            }

            // No support for float/double/decimal/... yet
            if (IsNumericLiteral(part))
            {
                literal = int.Parse(part);
                continue;
            }

            var propOrOp = part.ToLowerInvariant();
            if (IsOperator(propOrOp))
            {
                @operator = propOrOp;
                continue;
            }

            property = propOrOp;
        }

        newFilter.Append(UseOperator(@operator, property, paramIndex++));
        paramList.Add(literal);

        // We only support "and" and "or". No ! or () allowed.
        if (i < filterParts.Length)
        {
            newFilter.Append(string.Equals(filterParts[i++], "and", StringComparison.OrdinalIgnoreCase) ? " &amp;&amp; " : " || ");
        }
    }

    return new ParsedFilter(newFilter.ToString(), paramList);
}

private bool IsNumericLiteral(string literal)
{
    var rxNumeric = new Regex(@"^-?\d+(,\d+)*(\.\d+(e\d+)?)?$");
    return rxNumeric.IsMatch(literal);
}

private bool IsBoolLiteral(string literal)
{
    return string.Equals(literal, "true", StringComparison.OrdinalIgnoreCase) ||
           string.Equals(literal, "false", StringComparison.OrdinalIgnoreCase);
}

private bool IsStringLiteral(string literal)
{
    return literal.StartsWith("\"", StringComparison.Ordinal) &&
           literal.EndsWith("\"", StringComparison.Ordinal);
}

private bool IsOperator(string @operator)
{
    switch (@operator)
    {
        case "eq":
        case "ne":
        case "lt":
        case "le":
        case "gt":
        case "ge":
        case "sw":
        case "ew":
        case "co":
            return true;
    }

    return false;
}

private string UseOperator(string @operator, string property, int paramIndex)
{
    switch (@operator)
    {
        case "eq":
            return $"{property} = @{paramIndex}";
        case "ne":
            return $"{property} != @{paramIndex}";
        case "lt":
            return $"{property} < @{paramIndex}";
        case "le":
            return $"{property} <= @{paramIndex}";
        case "gt":
            return $"{property} > @{paramIndex}";
        case "ge":
            return $"{property} >= @{paramIndex}";
        case "sw":
            return $"{property}.StartsWith(@{paramIndex})";
        case "ew":
            return $"{property}.EndsWith(@{paramIndex})";
        case "co":
            return $"{property}.Contains(@{paramIndex})";
    }

    return "";
}

private struct ParsedFilter
{
    public ParsedFilter(string filter, IEnumerable<object> paramList)
    {
        Filter = filter;
        ParamList = paramList;
    }

    public string Filter { get; }
    public IEnumerable<object> ParamList { get; }
}

• script-src 'self' allows loading scripts from the current domain
• child-src https://youtube.com allows the use of <iframe> tags pointing towards YouTube
• style-src 'self' https://maxcdn.bootstrapcdn.com allows loading CSS files from the current source and from a CDN.

If you want to read up on CSP, I suggest heading over to http://www.html5rocks.com/en/tutorials/security/content-security-policy/.

Now, I was trying out some things concerning CSP and inline scripts. You could add 'unsafe-inline' to the script-src source list to allow all inline scripting (except eval and other bad stuff, you need 'unsafe-eval' in that case), but that is exactly what you would want to avoid. Instead, you can opt to do one of these things:

1. Move all inline JavaScript into .js files and load them using <script src=""></script> tags, while adding 'self' to script-src if that wasn't already the case. The easiest solution, but not always possible.
2. Generate a nonce for each inline script. A nonce means: a unique and hard to predict stream of bytes, different for each script, each page and each request! A nonce could be base64 encoded and look like RJ6bGjm5EO/X8pImZjvjeAexFVei9IvzNFCGw5lQUa0= You would need to add that nonce to the script using the nonce attribute, and also to the script-src source list using 'nonce-RJ6bGjm5EO/X8pImZjvjeAexFVei9IvzNFCGw5lQUa0='
3. Calculate the SHA256, SHA384 or SHA512 digest of each inline script (including all whitespace, but excluding the opening and closing script tags). Like the nonce, you'd need to add these digests to the script-src source list using 'sha256-0ZMofb7eMqkB9IFHnGVZ6Z4chjplAavgi09shinNehs=' for example.

Options 2 and 3 however are only defined in CSP v2, which is currently only implemented by Chrome, Opera and Firefox. The safest method would be to use the hash digest method, option 3. Alas, when you choose option 3, you'll quickly run into the following issues:

• Chrome. I'm running version 46.0.2490.80 m on a Windows PC and Chrome keeps telling me this:

  Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'sha256-0ZMofb7eMqkB9IFHnGVZ6Z4chjplAavgi09shinNehs='". Either the 'unsafe-inline' keyword, a hash ('sha256-G3FpTn2EFU91Umz2fz6NyjnqeGDTr8SUdmWbsvxzfbY='), or a nonce ('nonce-...') is required to enable inline execution.
  

  The issue? My script block contains carriage returns for readability. You know, those '\r\n' thingies which tend to differ sometimes, depending on the OS you're running. But I'm running on Windows and hosting my website locally. Yet Chrome has stripped the '\r' characters from the script before calculating the SHA256 hash to verify my script block... Ugh.

• Firefox. Version 41.0.2, catching up to Chrome apparently. Loading my test site and...

  Content Security Policy: The page's settings blocked the loading of a resource at self ("script-src http://localhost:21275 'sha256-0ZMofb7eMqkB9IFHnGVZ6Z4chjplAavgi09shinNehs='")
  

• Edge. The newest browser from Microsoft, which I really want to start to use. But then I bump, as expected, into:

  CSP14304: Unknown source ''sha256-0ZMofb7eMqkB9IFHnGVZ6Z4chjplAavgi09shinNehs='' for directive 'script-src' in Content-Security-Policy - source will be ignored.
  

• Let's try Internet Explorer, version 11.0.10240.16431. I'll dump the entire console output to share this with you:

  Navigation occurred.
  localhost:21275
  test
  

  Amazing, no? Wait, let's try something else here. Let's remove the hash from the header, that should stop the script from running. I'll dump the console output again:

  Navigation occurred.
  localhost:21275
  test
  

  So don't be fooled here. Internet Explorer doesn't support CSP v2, and even v1 is only partially supported.

Let's try option 2 instead: making use of a nonce for every script block. This time, the results are looking a little bit better:

• Chrome is happily executing the script now.
• So is Firefox, but Firefox keeps complaining about another script. I have no clue which one. I could try to find out, using the CSP reporting options, but I'm not going to bother.

So there you have it: Content Security Policy is still not fully there yet. You can use it though, to restrict the use of other content, like webfonts, style sheets, media, ..., but for scripts our options are currently limited to either opening up 'unsafe-inline' or moving all JavaScript into files. And if you're doing ASP.NET projects, have a look at https://www.nuget.org/packages/NWebsec. This NuGet package will make implementing CSP - and other security headers - a lot easier for you :)

• AnchorTagHelper: allows you to write <a asp-controller="Home" asp-action="Index">Back to home</a> instead of @Html.ActionLink("Back to home", "Index", "Home")
• LabelTagHelper, InputTagHelper, TextAreaTagHelper, SelectTagHelper, etc.: instead of writing Razor like @Html.LabelFor(m => m.Property1, new { @class = "control-label col-md-2"}), you can use a syntax which is much cleaner: <label asp-for="Property1" class="control-label col-md-2"></label>
• EnvironmentTagHelper: adds a new tag, <environment>, giving you the possibility to include <link> or <script> tags specific for Development or Production environments.
• LinkTagHelper, ScriptTagHelper: adds attributes to <link> and <script> to allow the use of CDN's and fallback urls. This list is incomplete, but you can head over to GitHub to see every available TagHelper class currently available.

You can also create your own TagHelper classes. I'll show you an example which enables you to do this:

<img asp-controller="Users" asp-action="ProfileImage" asp-route-id="@currentUserId" />

That <img> tag would load a users profile image using the ProfileImage action method in a UsersController class: useful for retrieving a profile image from a blob container on Azure, for example.

To create a custom TagHelper class, start by adding a dependency to the Microsoft.AspNet.Razor.Runtime NuGet package in project.json. You can add this dependency to the top list of global dependencies:

{
  "webroot": "wwwroot",
  "version": "1.0.0-*",

  "dependencies": {
    "Microsoft.AspNet.Diagnostics": "1.0.0-beta8",
    "Microsoft.AspNet.IISPlatformHandler": "1.0.0-beta8",
    "Microsoft.AspNet.Mvc": "6.0.0-beta8",
    "Microsoft.AspNet.Mvc.TagHelpers": "6.0.0-beta8",
    "Microsoft.AspNet.Server.Kestrel": "1.0.0-beta8",
    "Microsoft.AspNet.StaticFiles": "1.0.0-beta8",
    "Microsoft.AspNet.Tooling.Razor": "1.0.0-beta8",
    "Microsoft.Framework.Configuration.Json": "1.0.0-beta8",
    "Microsoft.Framework.Logging": "1.0.0-beta8",
    "Microsoft.Framework.Logging.Console": "1.0.0-beta8",
    "Microsoft.Framework.Logging.Debug": "1.0.0-beta8",
    "Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0-beta8",
    "Microsoft.AspNet.Razor.Runtime":  "4.0.0-beta8"
  },

...

Next, add a new Class to your MVC project. Let's call this class ImageTagHelper, and let the class derive from the TagHelper class which lives in the Microsoft.AspNet.Razor.Runtime.TagHelpers namespace. We're going to add three new attributes to the <img> tag:

• asp-controller: the MVC Controller
• asp-action: the action method within the controller
• asp-route-*: route values for the action method

For each of these attributes, add a class level HtmlTargetElementAttribute:

[HtmlTargetElement("img", Attributes = ActionAttributeName)]
[HtmlTargetElement("img", Attributes = ControllerAttributeName)]
[HtmlTargetElement("img", Attributes = RouteValuesPrefix + "*")]
public class ProfileImageTagHelper : TagHelper
{
    private const string ActionAttributeName = "asp-action";
    private const string ControllerAttributeName = "asp-controller";
    private const string RouteValuesPrefix = "asp-route-";
}

I'm using constants here to define the attribute names: I can reuse these later when adding the properties which will receive the values of the HTML attributes. Let's add these properties now:

[HtmlTargetElement("img", Attributes = ActionAttributeName)]
[HtmlTargetElement("img", Attributes = ControllerAttributeName)]
[HtmlTargetElement("img", Attributes = RouteValuesPrefix + "*")]
public class ProfileImageTagHelper : TagHelper
{
    private const string ActionAttributeName = "asp-action";
    private const string ControllerAttributeName = "asp-controller";
    private const string RouteValuesPrefix = "asp-route-";

    /// <summary>
    /// The name of the action method.
    /// </summary>
    [HtmlAttributeName(ActionAttributeName)]
    public string Action { get; set; }

    /// <summary>
    /// The name of the controller.
    /// </summary>
    [HtmlAttributeName(ControllerAttributeName)]
    public string Controller { get; set; }

    /// <summary>
    /// Additional parameters for the route.
    /// </summary>
    [HtmlAttributeName(DictionaryAttributePrefix = RouteValuesPrefix)]
    public IDictionary<string, string> RouteValues { get; set; } =
        new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);
}

By using a * at the end of the HtmlTargetElementAttribute, we can map multiple values into an IDictionary<string, string>. Think of this as a way to specify only one property to hold all data-* attributes. It is now time to add the logic which will make this TagHelper work. Let's override the Process method:

public override void Process(TagHelperContext context, TagHelperOutput output)
{
    if (context == null)
    {
        throw new ArgumentNullException(nameof(context));
    }

    if (output == null)
    {
        throw new ArgumentNullException(nameof(output));
    }

    // If "src" is already set, it means the user is attempting to use a normal img tag.
    if (output.Attributes.ContainsName("src"))
    {
        if (Action != null ||
            Controller != null ||
            RouteValues.Count != 0)
        {
            // User specified an src and one of the bound attributes; can't determine the src attribute.
            throw new InvalidOperationException(
                "Cannot override the src attribute of an <img> tag if the src attribute has a value.");
        }
    }
    else
    {
        // Convert from Dictionary<string, string> to Dictionary<string, object>.
        var routeValues = RouteValues.ToDictionary(
            kvp => kvp.Key,
            kvp => (object) kvp.Value,
            StringComparer.OrdinalIgnoreCase);

        var tagBuilder = new TagBuilder("img");
        tagBuilder.MergeAttribute("src", _urlHelper.Action(Action, Controller, routeValues));

        output.MergeAttributes(tagBuilder);
    }
}

First of all, we check if the consumer of this custom TagHelper hasn't set a value for the src attribute, because then the <img> tag would just need to look at the original URI to retrieve the image. We will however show an error when the src attribute and one of our custom attributes has been set together. If the developer is using our TagHelper without a src attribute, then we'll fill in the attribute ourselves using _urlHelper.Action(): that's the @Url.Action method you've been using in Razor all along. Of course, we still need to add that _urlHelper instance to our class and inject it. Here is the final version of our TagHelper class code:

using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.AspNet.Mvc;
using Microsoft.AspNet.Mvc.Rendering;
using Microsoft.AspNet.Mvc.TagHelpers;
using Microsoft.AspNet.Razor.Runtime.TagHelpers;

namespace CustomTagHelperDemo.TagHelpers
{
    [HtmlTargetElement("img", Attributes = ActionAttributeName)]
    [HtmlTargetElement("img", Attributes = ControllerAttributeName)]
    [HtmlTargetElement("img", Attributes = RouteValuesPrefix + "*")]
    public class ProfileImageTagHelper : TagHelper
    {
        private readonly IUrlHelper _urlHelper;

        private const string ActionAttributeName = "asp-action";
        private const string ControllerAttributeName = "asp-controller";
        private const string RouteValuesPrefix = "asp-route-";

        public ProfileImageTagHelper(IUrlHelper urlHelper)
        {
            _urlHelper = urlHelper;
        }

        /// <summary>
        /// The name of the action method.
        /// </summary>
        /// <remarks>Must be <c>null</c> if <see cref="Route"/> is non-<c>null</c>.</remarks>
        [HtmlAttributeName(ActionAttributeName)]
        public string Action { get; set; }

        /// <summary>
        /// The name of the controller.
        /// </summary>
        /// <remarks>Must be <c>null</c> if <see cref="Route"/> is non-<c>null</c>.</remarks>
        [HtmlAttributeName(ControllerAttributeName)]
        public string Controller { get; set; }

        /// <summary>
        /// Additional parameters for the route.
        /// </summary>
        [HtmlAttributeName(DictionaryAttributePrefix = RouteValuesPrefix)]
        public IDictionary<string, string> RouteValues { get; set; } =
            new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);

        /// <summary>
        /// Synchronously executes the <see cref="T:Microsoft.AspNet.Razor.Runtime.TagHelpers.TagHelper"/> with the given <paramref name="context"/> and
        ///             <paramref name="output"/>.
        /// </summary>
        /// <param name="context">Contains information associated with the current HTML tag.</param><param name="output">A stateful HTML element used to generate an HTML tag.</param>
        /// <remarks>Does nothing if user provides an <c>src</c> attribute.</remarks>
        /// <exception cref="InvalidOperationException">
        /// Thrown if <c>src</c> attribute is provided and <see cref="Action"/> or <see cref="Controller"/> are
        /// non-<c>null</c> or if the user provided <c>asp-route-*</c> attributes.
        /// </exception>
        public override void Process(TagHelperContext context, TagHelperOutput output)
        {
            if (context == null)
            {
                throw new ArgumentNullException(nameof(context));
            }

            if (output == null)
            {
                throw new ArgumentNullException(nameof(output));
            }

            // If "src" is already set, it means the user is attempting to use a normal anchor.
            if (output.Attributes.ContainsName("src"))
            {
                if (Action != null ||
                    Controller != null ||
                    RouteValues.Count != 0)
                {
                    // User specified an href and one of the bound attributes; can't determine the href attribute.
                    throw new InvalidOperationException(
                        "Cannot override the src attribute of an <img> tag if the src attribute has a value.");
                }
            }
            else
            {
                // Convert from Dictionary<string, string> to Dictionary<string, object>.
                var routeValues = RouteValues.ToDictionary(
                    kvp => kvp.Key,
                    kvp => (object) kvp.Value,
                    StringComparer.OrdinalIgnoreCase);

                var tagBuilder = new TagBuilder("img");
                tagBuilder.MergeAttribute("src", _urlHelper.Action(Action, Controller, routeValues));

                output.MergeAttributes(tagBuilder);
            }
        }
    }
}

But we're not done, yet. To be able to use custom TagHelper classes, you'll need to let Razor know about them. Open the _ViewImports.cshtml file in the Views/Shared folder and add the following line:

@addTagHelper "*, CustomTagHelperDemo"

This line will tell Razor to load all TagHelper derived classes from the assembly CustomTagHelperDemo. You can also use the name of a specific TagHelper class instead of an asterisk. Also, don't forget to replace CustomTagHelperDemo with the name of your project or class library. And now, you can open up a Razor file and tryout the new features you've added to the tag:

<ul class="nav navbar-nav navbar-right">
    @if (User.Identity?.IsAuthenticated == true)
    {
        <li>
            <img asp-controller="Users" asp-action="ProfileImage" asp-route-id="@User.FindFirst("sub").Value" />
            <a asp-controller="Account" asp-action="Logoff">Sign out</a>
        </li>
    }
    else
    {
        <li>
            <a asp-controller="Account" asp-action="Logon">Sign in</a>
        </li>
    }
</ul>