My OwaspHeaders.Core middleware hit version 18.104.22.168 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.
I recently upgraded dwCheckApi to .NET Core 2.0, but the deployment didn't go so well. Want to know why and how to avoid it happening to you? Then click through and read on.
Today’s header image was created by Roberto Catarinicchia at Unsplash Caveat Just a quick note before we begin. A caveat
JetBrains (maker of IntelliJ IDEA) recently released the initial version of Rider - their open source .NET/.NET Core IDE. That's right: version 1 is out, after a few years of development. But is it any good?
Committing passwords, api keys and connection strings to open source projects can be incredibly dangerous. Even once they've been removed from the repo they can still be found in the commit history. The .NET Core boffins have come up with a technique called User Secrets, which is meant to help alleviate this. What are they and how do they work? In this post, we'll find out.
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