Paul Hatcher

I’ve released a little project Meerkat.NameParser which assists in splitting up personal names into their component parts.

This code has been around in one form or another since around 1988 when I wrote the first version in Informix 4GL as part of a project for a client. Subsequent versions were written in Clipper, Visual Basic and this one in C#.

It’s not perfect by any means but on projects I’ve used it on we were getting error rates of ~2 per 100K.

One of my current projects is using SpecFlow for testing some complex security logic; there are lots of scenarios so the BDD style of testing is well suited to the problem. I wanted to use the same style of testing for some integration testing where the client is talking to my API but hit a problem of how/where to construct the container as even the client library uses dependency injection to construct itself.

Couple of changes released today, one to Meerkat.Security and the other to Meerkat.Caching.

The first was to introduce handling for grant/deny of actions for unauthenticated users. I’d missed this use case before as to date, the project was just used in a corporate Windows environment and so everyone was authenticated by the time we saw them.

As I’m now working on a project using Azure B2C Active Directory we are now back to the point where users need to authenticate, so you want to filter the actions they can see/perform before and after they authenticate, e.g. you want to allow unauthenticated users access to Home.Index and error pages but probably not much more, and as the principle of the project was to centralize the security checking, we need a way to allow unauthenticated users without using AllowAnonymous on the controller action.

I’ve just started blogging again and decided to adopt MiniBlog, a minimal modern blog engine written by Mads Kristensen who also wrote BlogEngine.NET, as SubText has died.

It only has a small set of features and Mads intends to keep it like this, the concept is that you make your own fork on GitHub, adding the features you want and publish from there; this has a few consequences…

• Your blog credentials are visible in your GitHub fork
• Potentially your content is there as well
• How to test out new features written by yourself and/or from other forks.

I decided on a three branch strategy

I’m working on a project where we are using Azure B2C Active Directory to provide authentication so that we can avoid the security headaches associated with managing a password store for it.

Unfortunately, the current implementation doesn’t support .NET Windows applications or standalone services where no user-interface is present - it will eventually, but I can’t wait on the eventual delivery date for these two use-cases. I don’t want to re-introduce user name/password for this, as I’d introduce the same security issues that I was trying to avoid in the first place, but following a bit of research I decided the way forward was HMAC authentication.