My OwaspHeaders.Core middleware hit version 3.0.0.1 recently. The new version uses a new way to set it's configuration: the builder pattern. So I thought I'd write a little about how the builder pattern works and how it is used by ASP NET Core and my middleware.
The entirety of .NET Core's history is available online. It is one of Microsoft's first completely open frameworks, in that all of the important decisions have been made in the open and the source is completely open. Some of the key Microsoft employees even host a weekly show about it's development.
Today’s header image was created by Roberto Catarinicchia at Unsplash Caveat Just a quick note before we begin. A caveat
In this post we'll take a previously built custom middleware and finalise the configuration options to it. We'll complete the JSON file which represents the config, and ensure that it's being read and the values are applied to the middleware setup.
In this post we'll take a previously built custom middleware and add configuration options to it. We'll load our config options for the middleware from a JSON file present in the consuming application, and apply it to the middleare
Building on the previous post on ASP.NET Core middleware, I'll show you how to make your own. We'll use OWASP secure header guidelines to create our own middleware which will add the recommended headers to all requests.
What is middleware (in an ASP.NET Core context) and how does it work? Does the ASP.NET Core request pipeline differ to how the Classic ASP.NET request pipeline work? There's only one way to find out: read this article
In the final week of October of 2106, Microsoft announced the release of .NET Core 1.1. In this post I go through some of the changes and design decisions behind them. It's exciting stuff, if I do say so.
