Asp.Net Policy Authorization Based on a DB Field on the User Table

If you read this, you’ll learn how to create authorisation, based on a policy. Specifically, they use the example of the user’s age, and create a restriction to say that only users over the age of 21 can access a resource.

The age was something that they got from a claim, stored against the user. But what if your requirement is a little more complex? For example, what if you have a situation, such as a popular question and answer site that you may recognise, where you are trying to restrict access to a resource based on something that can change during the user session. In this post, I’m covering how you can follow the same policy structure, but force the program to go back to the DB to get details about the user, each time they try to access the restricted resource.

As a background, the particular use case here is that a user of my site can approve something, but only where they have a sufficient rating.

Basic Set-up

The first thing that you’ll need is a custom Authorization Handler. For my project, I’ve created a sub directory called Authorization (I’ve even spelled it wrong to be consistent):

The Authorization Handler inherits from an abstract class, which forces you to override a single method: HandleRequirementAsync. Essentially, you tell the handler about your requirement (we’ll come to the requirement next), and then it passes this back to you in the method; let’s have a look at some code:

    public class ApproverAuthHandler : AuthorizationHandler<ApproverAuthRequirement>
        protected override Task HandleRequirementAsync(
            AuthorizationHandlerContext context, 
            ApproverAuthRequirement requirement)

The Requirement is just a class to hold the relevant data that you need. In our example, the requirement would hold the user’s rating; here’s the requirement code:

    public class ApproverAuthRequirement : IAuthorizationRequirement
        public int UserRating { get; set; }

        public ApproverAuthRequirement(int userRating)
            UserRating = userRating;

IAuthorizationRequirment is what is known as a marker interface. To be honest, I hadn’t come across the term before, but I have used the pattern before. Essentially, this is an empty interface: its purpose it to allow you to pass the class type as a strongly typed interface; but in reality, the class can me anything.

Anyway, let’s get back to the Authorization Handler. Inside HandlerRequirementAsync, you can do anything you choose; should your check be successful, you call context.Succeed(requirement), otherwise, do nothing. In the above linked code, they check a claim against the requirement; we’re going to just get some information from the DB, and check that against the requirement:

        protected override Task HandleRequirementAsync(
            AuthorizationHandlerContext context, 
            ApproverAuthRequirement requirement)
            int? userRating = _userService.GetSubjectRating(context.User);            
            if (!userRating.HasValue)
                return Task.CompletedTask;

            if (userRating >= requirement.UserRating)

            return Task.CompletedTask;

User service is simply a service that calls into a repository, and returns the user rating.

Unit Testing

All well and good, and this looks eminently testable. In fact, it is: you simply mock out the service, and the test looks like this:

            // Arrange
            var requirements = new[] { new ApproverAuthRequirement(100) };            
            var user = new ClaimsPrincipal(
                        new ClaimsIdentity(
                            new Claim[] { },

            var userService = Substitute.For<IUserService>();

            var context = new AuthorizationHandlerContext(requirements, user, null);
            var sut = new ApproverAuthHandler(userService);

            // Act
            await sut.HandleAsync(context);

            // Assert

No doubt, you could check for the exact service principal under test, although you’re testing the Authorization Handler, so I think this is sufficient.

Resource Based Handler

In this article, there is a similar process discussed; it warrants some further investigation on my part, but I don’t currently see any real difference between my implementation, and this abstraction (although, admittedly, this version looks easier to test).


Force React Components to sit Side-by-Side

For anyone that knows me, they’ll know that UI and UX is not exactly my strong suit. If I had my way, we’d all just use console applications like this:

>placeorder /productcode coffee /quantity 1

Unfortunately, the trend seems to have gone a different way, and now we have CSS. CSS is a brilliant idea; however, you need to be able to visualise what you want your stuff to look like first.

Anyway, onto this post. If you know anything about CSS or Bootstrap, then you’ve probably already read everything that could interest you about this post!

In my latest project, I have a search box, and I wanted to line up the controls on the screen like this:

Search         [Search Text]        [Search Button]

I’m using React, so the original code looked like this (more or less):

<input type='text'/>
<SimpleButton buttonAction={props.searchAction} buttonLabel="Search" />            

And it rendered like this:

Search         [Search Text]        
[Search Button]

My first gambit was to define a CSS style (so I can now put “Front End Developer” on my CV):

.rowLine {

And I changed the HTML to look like this:

<div className='rowLine'>
    <input type='text'/>
    <SimpleButton buttonAction={props.searchAction} buttonLabel="Search" />            

That worked, and I copied most of it from here. So now I’ve updated my CV to “Senior Front End Developer”.

It then occurred to me that, as good as this looks, there’s probably something in Bootstrap, and if there is, then my web page can look like the rest of the internet. It turns out I was right:

<div className="form-group row">
    <label htmlFor="searchText" className="col-sm-2 col-form-label">Search</label>
    <div className="col-sm-8">
        <input id="searchText" className="form-control" type='text'
                    placeholder="e.g. Goats" />
    <div className="col-sm-2">
        <SimpleButton buttonAction={props.searchAction} buttonLabel="Search" />            

You may notice that React has its own “for” property, called “htmlFor”.

Disclaimer / Apology

As usual, please take everything you read in my blog with a healthy dose of salt. If you are a front end developer then please take solace in the fact that, despite me being facetious, I really need frameworks like Bootstrap, because I would never think to change the colour of a button, or to align the sizes.

This was all so much simpler in the days of Turbo Pascal / Turbo C, where you would draw your buttons using the ANSI character set!


Using XMLHttpRequest from Javascript to Call a .Net Core Api

Imagine you have the following API endpoint:


The controller method for this might look like this:

public IActionResult DoStuff([FromBody]Data data)

If, for example, you create the sample .Net Core React app, you’ll see it getting the data using a construct like this:

const response = await fetch('doStuff');

This works fine if you’re retrieving data, but if you want to send some data through to the endpoint body, XMLHttpRequest allows you to send data in the body like this:

const xhr = new XMLHttpRequest();'POST', 'doStuff')
xhr.setRequestHeader('Content-Type', 'application/json');
  data1: this.state.data1,
  data2: this.state.data2

Unsupported Media Type

If, in the above code, you were to use:

const xhr = new XMLHttpRequest();'POST', 'doStuff')
//xhr.setRequestHeader('Content-Type', 'application/json');
  data1: this.state.data1,
  data2: this.state.data2

You would be sending form data through to the controller. The call would not work, and you would get the following error from F12:

{"type":"","title":"Unsupported Media Type","status":415,"traceId":"|c86a375c-41ba2fd85652022a."}

There are two ways around this: the first, you’ve seen above, you set the content type; but you can also change the controller method to look like this:

public IActionResult DoStuff([FromForm]Data data)


Feature Flags – Asp.Net Core

Feature flags enable you to create a new piece of functionality in the main code branch, but behind a mask – so the end user doesn’t see the change. This means that you can decide at a later date to turn the feature on, or off. For example, say you wanted to make a change the colour of your web-site; or maybe you wanted to introduce an “Express Checkout” button; you can create these behind a feature flag, meaning that, should sales suddenly plummet when these changes are released, you can simply flick a switch to turn them off.

In this post, I’m going to cover the most basic usage of a feature flag. We’ll create a new web-site and, where a feature flag is turned on, we’ll show a button; and where it is not, we won’t. Before we start on the specifics, create a blank Asp.Net Core MVC project.

1. Add NuGet packages

The concept of feature flags exist outside of Microsoft. In fact, Feature Flags are just the idea of enabling functionality based on a setting, so there was probably one in the first computer program ever written. In this post, we’re talking about the implementation of this concept that’s available from Microsoft for Asp.Net Core.

The first step, as with more Microsoft libraries these days, is NuGet:

Install-Package Microsoft.FeatureManagement.AspNetCore

2. Add to DI

In Startup.cs, we’ll need to add the feature into the IoC. In the `ConfigureServices` method, add the following code:


3. Config appsettings.json

Add the following section to appsettings.json:

  "FeatureManagement": {
    "MyFeature": true

All we’re doing here is building up a key value pair underneath the “FeatureManagement” header. These settings can be more complex, but all we’re doing here is saying that our feature is on.

4. Inject the Functionality

Now that we’ve registered this in the IoC (using AddFeaturemanagement) we can inject it into our controller or service; for example:

public MyService(IFeatureManager featureManager)
    _featureManager = featureManager;

Then you can simply check whether the feature is enabled:

if (await featureManager.IsEnabledAsync("MyFeature")) { // Run the following code }

There is an intrinsic flaw with using magic strings like this – if you rename them, you could miss one. Microsoft recommend using an enum, such as this:

public enum MyFeatureFlags { FeatureA, FeatureB, FeatureC }

Which would enable you to reference it like this:

if (await featureManager.IsEnabledAsync(nameof(MyFeatureFlags.FeatureA)))

5. Access to controllers and views

You can hide an entire controller behind a flag; for example:

public class HomeController : Controller 
{ ... }

You can use these on specific controller actions, too.

We did say at the start of this post that we’d display a button when a flag was on, so let’s see what that would look like in the view; after all, whilst the rest of this is useful, the most likely thing that you’ll want to do in enabling or disabling a feature is change what the user can see. The following code would only show a button if “MyFeature” is on:

<feature name="MyFeature"> <button>MyFeature Button</button> </feature>

Summary and Notes

Seems pretty smooth to me. There are other feature flag managers out there; and, to be honest, it’s not like you couldn’t create your own in an hour or so, but this one struck me as a very neat option.

Also, because it’s from Microsoft, you can use Azure App Configuration to manage the flags; this gives you a proper UI to manage the flags. Obviously, if they’re in the appsetting.json, you have a number of other options, but if you’re using Azure, why not take advantage.


Change the Primary Key Type in Entity Framework

Imagine that you’ve created a Primary Key in Entity Framework (AFAIK, this applies to EF Core and EF 6), and it’s the wrong type: perhaps you created it as a Guid and decided it should be a string; obviously, if you created it as a string and you want it as an integer, then you have the same issue you have with any such change: EF doesn’t know how to change the text “Donald” into an integer any more than you do !

The Problem

Imagine you have a primary key PK_Duck on the table: Duck. The table has the following data:

Id Name Description
80c983c9-14d0-49b7-889d-a08b874d4629 Donald White with a blue coat
5f2178fa-2605-4f70-bdfd-a7f6e924aab0 Jemima White with a bonnet and shawl

If you just change the model / entity type from a Guid to a string, EF will generate something like the following migration:

                name: "Id",
                table: "Duck",
                nullable: false,
                oldClrType: typeof(Guid));

If you try to update the DB, you’ll get the following error:

The object ‘PK_Duck’ is dependent on column ‘Id’.
ALTER TABLE ALTER COLUMN Id failed because one or more objects access this column.

The Solution

The solution here is actually quite straightforward, and exactly what you would do in raw SQL; you just drop the primary key. Manually change the migration to drop the key first, and then re-create it afterwards:

migrationBuilder.DropPrimaryKey("PK_Duck", "Duck");

                name: "Id",
                table: "Duck",
                nullable: false,
                oldClrType: typeof(Guid));

migrationBuilder.AddPrimaryKey("PK_Duck", "Duck", "Id");

Moving to Typescript with React

Typescript gives you a number of nice little statically typed features, which Javascript is sadly lacking. However, looking online, most of the tutorials and references use Javascript. This is a handy little post to allow you (or me) to use Typescript; or to use Javascript, and then transition to Typescript. Since you can use both in your project, you might find that migrating files one at a time allow you to gradually transition your code-base.

File name

When you create your first React app, you get a, by now, pretty standard SPA app. The entire app is running Javascript. To change one of the files over to Typescript, simply change the extension:

You now have your first Typescript component… Now the errors begin!


Parameter ‘props’ implicitly has an ‘any’ type, but a better type may be inferred from usage.ts(7044)

This warning appears when you have the following constructor:

constructor(props) {  

Now that you’ve moved from a dynamic to a statically* typed language, Typescript is simply suggesting that you may have a better type than the Any** type that is assigned by default.

The easiest, and best transition here is simply to tell Typescript the type; for example:

interface IProps {

export class Home extends Component<IProps> {

  constructor(props: IProps) {    

If you actually have any properties, then you’ll need to include them in your interface; for example:

interface IProps {
  myValue: boolean


In Javascript, you define state by usage in the constructor; for example:

export class FetchData extends Component {
  static displayName =;
  constructor(props) {
    this.state = { forecasts: [], loading: true };

Again, you need to define what the structure of state is:

interface IState {
  forecasts: string[];
  loading: boolean;

Then, you can reference that in the constructor, and pass the type into the base component:

export class Home extends Component<IProps, IState> {

  constructor(props: IProps, ) {    
    this.state = { 
      forecasts: [], 
      loading: true 

External Interface Files

One of the consequences of declaring these interfaces, is that you’ll quickly find that you need to reference the same interface from more than one place. For example, you may read some data in one component, and then display it in another. You could simply redeclare the interface in both places, but that feels dirty.

To get around this, you can simply declare a set of interfaces in a single file, or set of files. In C#, I would declare a single interface per file, so I’m tempted to lean towards this approach:

This doesn’t necessarily apply to any interfaces that are relevant to only a single component (for example, the interface for the props – unless they are shared – feels like it’s perfectly happy in the same file as the component).

Raising Events

In the same way as you now have to define what props look like, when you raise an event, you need to define what the event looks like; that is, you must tell Typescript the event type that you’re handling.

interface SearchProps {
    searchText: string;
    searchAction: (e: React.MouseEvent<HTMLButtonElement>) => void;
function Search(props: SearchProps) {
    return (
            <button onClick={props.searchAction}>Search</button>
export default Search;

External Libraries

If you’re referencing an external library, you may not have the Typescript definitions; let’s take reactstrap for example:

Could not find a declaration file for module ‘reactstrap’. ‘c:/myproject/ClientApp/node_modules/reactstrap/dist/reactstrap.cjs.js’ implicitly has an ‘any’ type.

Try `npm install @types/reactstrap` if it exists or add a new declaration (.d.ts) file containing `declare module ‘reactstrap’;`ts(7016)

You should be able to simply install this – which, in fact, it tells you to do in the error message:

npm install @types/reactstrap



* I’m not convinced that Typescript qualifies as a true statically typed language, rather it provides static typing for a dynamically typed language.

** Any is Typescript’s way of allowing you to revert to JavaScript, and just not type a specific variable; this is why I have doubts as to whether Typescript can be considered statically typed.

An assembly specified in the application dependencies manifest was not found… strange errors when trying to create an EF migration

This has been on my list to write up for some time, but this must be the third or fourth time I’ve encountered it – each time I get a vague sense that I’ve been here before.

Setting the Scene

It’s Friday afternoon, and you’re trying to create a migration, so you can check your code in and go home… or to the pub. Disaster strikes, you get the following error:

An assembly specified in the application dependencies manifest (MyProject.deps.json) was not found:
package: ‘Some.Package’, version: ‘1.0.0’
path: ‘Some.Package.dll’

You panic – there’s a pint of Doom Bar with your name on it, and it’s getting cold. You do a quick search, and you find this post… actually, it doesn’t matter what I write here – you’ll just see the title and scroll down to the answer. The Pigeon King is called Donald; there are 336 holes in your average golf ball; there’s nobody on the 37th floor, and nobody knows why.

The Answer

The answer is either that you have the incorrect project, or startup project. You can change both of these manually, or simply specify them in the migration; for example:

Add-Migration MigrationName -Context AppDbContext -StartupProject MyProject -Project MyProject.DataAccess

In my specific case, I had an Azure function set as the start-up project.

An ADR Visual Studio Tool – Part 7 – Adding a Context Menu Item

In my previous post I continued with my little series on writing an extension for Visual Studio by completing the functionality to view existing ADRs within the solution. You can see the first post here

In this post, we’ll cover the process of adding a command to the solution and project context menu. Having completed the screen that will show existing ADRs, we now want to allow the user to right-click on a project or solution and select to add a new ADR:

The first step is to add the command; fortunately, this is a pre-made template, so just select to add a new item (ironically), and pick Command:

This will create you a menu item that will appear under the Tools menu by default, and will display a message box when selected:

There are two things that we need to change about this command: the text (we don’t want it to read “Invoke AddAdrCommand”), and the location (we want it to be available from the right-click context menu of a project). Both of those things are changed in the file AdrPackage.vsct (if your project is called Aardvark, this will be named AardvarkPackage.vsct).

If you have a look in that file, you’ll see something called MyMenuGroup; which is referenced in three places. The first defines what it is:

This is where you can change the command text (as I have above).

The second, where it is:

This initially looks like this:

<Parent guid="guidSHLMainMenu" id="IDM_VS_MENU_TOOLS" />

Which adds the menu to the top level Tools menu; change it to:

<Parent guid="guidSHLMainMenu" id="IDM_VS_CSCD_PROJECT_ADD" />

As I have.

There are other options here.

The third is the ID Symbol:

If you decide to change the name of MyMenuGroup, you will need to do so in all three places above.

Getting the Context of the Current Project

Now that we’ve moved the menu to the context menu, we’ll need to find which project we’re in by accessing the DTE Service – this is retrieved by calling the command:

            var dte = await package.GetServiceAsync(typeof(DTE)).ConfigureAwait(false) as DTE2;

You can then find out what’s selected by accessing the selected hierarchy:

            UIHierarchy uih = (UIHierarchy)dte.Windows.Item(
            Array selectedItems = (Array)uih.SelectedItems;

Here’s the full code of the Execute method, to display the selected project:

        private async void Execute(object sender, EventArgs e)
            await ThreadHelper.JoinableTaskFactory.SwitchToMainThreadAsync(package.DisposalToken);

            var dte = await package.GetServiceAsync(typeof(DTE)).ConfigureAwait(false) as DTE2;

            UIHierarchy uih = (UIHierarchy)dte.Windows.Item(
            Array selectedItems = (Array)uih.SelectedItems;
            foreach (UIHierarchyItem selectedItem in selectedItems)
                // Show a message box to prove we were here
                    "Selected Project",

We’re not far off now – there’s a few little issues, but the main thing that’s left is that we’re not actually adding anything – just displaying a message. The next step is to get it to actually add a file, but we’ll come to that in the next post.

The code for this project can be found here.


Unit Testing EF Core – How to Invoke the Contents of OnModelCreating

In this post, I wrote about how you can test an EF Database, using an InMemory database.

I’m guessing a few people reading this will be thinking this is stating the bloody obvious, but it certainly wasn’t to me. Imagine you have a DBContext with some seed data; for example:

        protected override void OnModelCreating(ModelBuilder modelBuilder)

                new EntityType1
                    Id = "1",
                    Name = "Test1",
                    Description = "Testing",
                    IsTest = true,
                    SomeNumber = 1

In the above linked article, this seed data will never fire; however, simply calling:


Once the context is created, will force the migrations to be run inside the in-memory instance, and you should end up with a system mirroring what you would see, should you run this migration against a physical database.

Caveat Emptor

When using this against EF Core 2.2 I found, what appeared to be, this issue. The error being, while I was trying to insert a record, an error returned saying that an item with the same key exists on the table. However, no such item should exist. The linked article seems to imply that this relates to a bug with the insert for the in-memory database, and that it is resolved for EF Core 3.0. I haven’t validated this, so it may, or may not work to upgrade to EF Core 3.0. Please add a comment if you can validate or negate this.


Add HttpClientFactory to an Azure Function

Since I first wrote about dependency injection in Azure Functions things have moved on a bit. These days, the Azure Functions natively* support DI. In this post, I’ll cover, probably the most common, DI scenario: adding HttpClientFactory to your project.

I’ll assume that you have an Azure function, and that it looks something like this:

    public static class Function1
        public static async Task<IActionResult> Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] HttpRequest req,
            ILogger log)
            log.LogInformation("C# HTTP trigger function processed a request.");

            string name = req.Query["name"];

            string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
            dynamic data = JsonConvert.DeserializeObject(requestBody);
            name = name ?? data?.name;

            return name != null
                ? (ActionResult)new OkObjectResult($"Hello, {name}")
                : new BadRequestObjectResult("Please pass a name on the query string or in the request body");

I’ll assume that, because that’s the default HTTP Trigger function you get when you select to create a new function.

NuGet Packages

You’ll need a few NuGet packages; first, you’ll need:

Install-Package Microsoft.Extensions.Http

Which will allow you to use the HttpClientFactory. You’ll also need some packages for the DI:

Install-Package Microsoft.Azure.Functions.Extensions
Install-Package Microsoft.NET.Sdk.Functions


If you create a new MVC project, you get a Startup class, which manages all your DI, etc. So we’re going to create one here. Create a Startup.cs class in the function app:

    public class Startup : FunctionsStartup
        public override void Configure(IFunctionsHostBuilder builder)

The Configure method is a member of FunctionsStartup (ctrl-. to add the override). You’ll also need to add the following line outside of the namespace:

[assembly: FunctionsStartup(typeof(FullNamespace.Startup))]

Essentially, FullNamepsace here refers to the fully qualified Startup class in your project. Without this line, nothing will be added to the IoC container.

The AddHttpClient call inside Configure adds HttpClientFactory to your IoC container.

Azure Function

If you have a look at the code above, you’ll notice the class is static. We can’t have constructor injection into a static class (because we can’t have a constructor); let’s change that to an instance class:

        public Function1(IHttpClientFactory httpClientFactory)
            _httpClientFactory = httpClientFactory;

You’ll also need to change the function itself from static to instance:

        public async Task<IActionResult> Run(

That’s it – you can now reference HttpClientFactory from inside your function.


* Maybe not exactly ‘natively’