GitHub - grantcolley/headway: A .NET 7.0 Blazor framework for building configurable applications fast. Supporting both hosting models, Blazor WebAssembly and Blazor Server, a WebApi for accessing data and an Identity Provider for authentication.

.NET 7.0, Blazor WebAssembly, Blazor Server, ASP.NET Core Web API, Auth0, IdentityServer4, OAuth 2.0, MudBlazor, Entity Framework Core, MS SQL Server, SQLite

Headway is a framework for building configurable Blazor applications fast. It is based on the blazor-solution-setup project, providing a solution for a Blazor app supporting both hosting models, Blazor WebAssembly and Blazor Server, a WebApi for accessing data and an Identity Provider for authentication.

The Framework
Getting Started
- Seed Data
Building an Example Headway Application
Authentication
Tracking Changes
Logging
- Send logs from the Client
- Configure Logging
Authorization
Navigation Menu
Page Layout
- Page Rendering
Documents
Components
Configuration
Administration
Database
UML Diagrams
- Blazor Server OnStart
- ClaimModules API
Notes
Acknowledgements

The Framework

Headway.BlazorWebassemblyApp - Blazor WASM running client-side on the browser.
Headway.BlazorServerApp - Blazor Server running updates and event handling on the server over a SignalR connection.
Headway.Razor.Shared - A Razor Class Library with shared components and functionality serving both Blazor hosting models.
Headway.Razor.Controls - A Razor Class Library containing common Razor components.
Headway.Core - A Class Library for shared classes and interfaces.
Headway.RequestApi - a Class Library for handling requests to the WebApi.
Headway.WebApi - An ASP.NET Core Web API for authenticated users to access data persisted in the data store.
Headway.Repository - a Class Library for accessing the data store behind the WebApi.
Identity Provider - An IdentityServer4 ASP.NET Core Web API, providing an OpenID Connect and OAuth 2.0 framework, for authentication.

Getting Started

Seed Data

To help get you started the Headway framework comes with seed data that provides basic configuration for a default navigation menu, roles, permissions and a couple of users.

The default seed data comes with two user accounts which will need to be registered with an identity provider that will issue a token to the user containing a RoleClaim called headwayuser. The two default users are:

User Headway Role Indentity Provider RoleClaim

[email protected] Admin headwayuser

[email protected] Developer headwayuser

The database and schema can be created using EntityFramework Migrations.

Building an Example Headway Application

An example application will be created using Headway to demonstrate features available the Headway framework including, configuring dynamically rendered page layout, creating a navigation menu, configuring a workflow, binding page layout to the workflow, securing the application using OAuth 2.0 authentication and restricting users access and functionality with by assigning roles and permissions.

Introduction to RemediatR

The example application is called RemediatR. RemediatR will provide a platform to refund (remediate or redress) customers that have been wronged in some way e.g. a customer who bought a product that does not live up to it's commitments. The remediation flow will start with creating the redress case with the relevant data including customer, redress program and product data. The case progresses to refund calculation and verification, followed by sending a communication to the customer and finally end with a payment to the customer of the refunded amount.

Different users will be responsible for different stages in the flow. They will be assigned a role to reflect their responsibility. The roles will be as follows:

Redress Case Owner – creates, monitors and progresses the redress case from start through to completion
Redress Reviewer – reviews the redress case at critical points e.g. prior to customer communication or redress completion
Refund Assessor – calculates the refund amount, including any compensatory interest due
Refund Reviewer – reviews the refund calculated as part of a four-eyes check to ensure the refunded amount is accurate

The RemediatR Flow is as follows:

Building RemediatR in Easy Steps

RemediatR can be built using the Headway platform in several easy steps involving creating a few models and repository layer, and configuring the rest.

Create

1. Create the RemediatR Projects

2. Create the Models and Interfaces

In Headway.RemediatR.Core
- Add a reference to project Headway.Core
- Create the model classes.
- Create the IRemediatRRepository interface.

3. Create the Repository

This example uses EntityFramework Code First.

In Headway.RemediatR.Repository
- Add a reference to project Headway.Repository
- Add a reference to project Headway.RemediatR.Core
- Create RemediatRRepository class.
In Headway.Repository
- Add a reference to project Headway.RemediatR.Core
- Update ApplicationDbContext with the models
Create the schema and update the database
- In Visual Studio Developer PowerShell
- > cd Headway.WebApi
- > dotnet ef migrations add RemediatR --project ..\Utilities\Headway.MigrationsSqlServer
- > dotnet ef database update --project ..\Utilities\Headway.MigrationsSqlServer

4. Create WebApi Access

In Headway.RemediatR.Core
- Create the RemediatRRoles constants.
In Headway.WebApi
- Create the RemediatR controller classes.

5. Create the WebApi Controllers

In Headway.WebApi
- Add a reference to project Headway.RemediatR.Core
- Add a reference to project Headway.RemediatR.Repository
- Create the RemediatRCustomerController controller.
- Create the RemediatRProgramController controller.
- Create the RemediatRRedressController controller.
- Add a scoped service for IRemediatRRepository to Program.cs
  builder.Services.AddScoped<IRemediatRRepository, RemediatRRepository>();

6. Create model Options

In Headway.Repository
- Add GetCountryOptionItems method to OptionsRepository

7. Create model validation

In Headway.WebApi

add package <PackageReference Include="FluentValidation.AspNetCore" Version="11.1.2" />
add to Program.cs

builder.Services.AddControllers()
    .AddFluentValidation(
        fv => fv.RegisterValidatorsFromAssembly(Assembly.Load("Headway.RemediatR.Core")))

In Headway.RemediatR.Core
- add package <PackageReference Include="FluentValidation" Version="11.1.0" />
- add validators:

Reference

In Headway.BlazorServerApp
- Add a project reference to Headway.RemediatR.Core
- add to Program.cs to ensure the RemediatR.Core assembly is eager loaded and it's classes available to be scanned for Headway attributes.
```
  app.UseAdditionalAssemblies(new[] { typeof(Redress).Assembly });
```
In Headway.BlazorWebassemblyApp
- Add a project reference to Headway.RemediatR.Core
- add to Program.cs to ensure the RemediatR.Core assembly is eager loaded and it's classes available to be scanned for Headway attributes.
```
  builder.Services.UseAdditionalAssemblies(new[] { typeof(Redress).Assembly });
```

Configure

1. Configure Authorisation

Seed data for RemediatR permissions, roles and users can be found in RemediatRData.cs.

Alternatively, permissions, roles and users can be configured under the Authorisation category in the Administration module.

2. Configure Navigation

Seed data for RemediatR navigation can be found in RemediatRData.cs

Alternatively, modules, categories and menu items can be configured under the Navigation category in the Administration module.

3. Configure Model Layout

Configure Programs search list
Configure Program model
Configure Customers search list
Configure Customer model
Configure Redress Cases search list
Configure New Redress Cases search list

4. Configure a Flow

5. Bind the Flow to a Model

6. Bind Permissions to the Flow

Authentication

Token-based Authentication

Blazor applications use token-based authentication based on digitally signed JSON Web Tokens (JWTs), which is a safe means of representing claims that can be transferred between parties. Token-based authentication involves an authentication server issuing an athenticated user with a token containing claims, which can be sent to a resource such as a WebApi, with an extra authorization header in the form of a Bearer token. This allows the WebApi to validate the claim and provide the user access to the resource.

Headway.WebApi authentication is configured for the Bearer Authenticate and Challenge scheme. JwtBearer middleware is added to validate the token based on the values of the TokenValidationParameters, ValidIssuer and ValidAudience.

builder.Services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
}).AddJwtBearer(options =>
{
    var identityProvider = builder.Configuration["IdentityProvider:DefaultProvider"];

    options.Authority = $"https://{builder.Configuration[$"{identityProvider}:Domain"]}";
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidIssuer = builder.Configuration[$"{identityProvider}:Domain"],
        ValidAudience = builder.Configuration[$"{identityProvider}:Audience"]
    };
});

Blazor applications obtain a token from an Identity Provider using an authorization flow. The type of flow used depends on the Blazor hosting model.

Blazor Server vs Blazor WebAssembly

ASP.NET Core Blazor authentication and authorization.
"Security scenarios differ between Blazor Server and Blazor WebAssembly apps. Because Blazor Server apps run on the server, authorization checks are able to determine:

The UI options presented to a user (for example, which menu entries are available to a user).

Access rules for areas of the app and components.

Blazor WebAssembly apps run on the client. Authorization is only used to determine which UI options to show. Since client-side checks can be modified or bypassed by a user, a Blazor WebAssembly app can't enforce authorization access rules. "

Blazor Server uses Authorization Code Flow in which a Client Secret is passed in the exchange. It can do this because it is a 'regular web application' where the source code and Client Secret is securely stored server-side and not publicly exposed.

Blazor WebAssembly uses Authorization Clode Flow with Proof of Key for Code Exchange (PKCE), which introduces a secret created by the calling application that can be verified by the authorization server. The secret is called the Code Verifier. It must do this because the entire source is stored in the browser so it cannot use a Client Secret because it is not secure.

The key difference between Blazor Server using the Authorization Code Flow and Blazor WebAssembly using the Authorization Clode Flow with Proof of Key for Code Exchange (PKCE), is Blazor Server can use a Client Secret in the exchange because it can be securely stored on the server. Blazor WebAssembly on the other hand cannot securely store a Client Secret so it has to create a code_verifier and then generate a code_challenge from it, which can be used in the exchange instead.

Authorization Code Flow vs Authorization Code Flow with PKCE

Authorization Code Flow steps:

User clicks login in the application.
The user is redirected to the authorization server (/authorize endpoint).
The authorization server redirects the user to a login prompt.
The user authenticates.
the authorization server redirects the user back to the application with an authorization code, which can only be used once.
The application sends the authorization code along with the applications Client ID and Client Secret to the authorization server (/oauth/token endpoint).
The authorization server verifies the authorization code, Client ID and Client Secret.
The authorization server sends to the application an ID Token and Access Token (and optionally, a Refresh Token) .
The Access Token contains user claims.
When the application wants to access a resource such as a WebApi it adds the Access Token containing user claims to the authorization header of a HttpClient request in the form of a Bearer token.

Authorization Clode Flow with Proof of Key for Code Exchange (PKCE) steps:
The PKCE Authorization Code Flow builds on the standard Authentication Code Flow so it has very similar steps.

User clicks login in the application.
The application creates a code_verifier and then generates a code_challenge from it.
The user is redirected to the authorization server (/authorize endpoint) along with the code_challenge.
The authorization server redirects the user to a login prompt.
The user authenticates.
the authorization server stores the code_challenge and then redirects the user back to the application with an authorization code, which can only be used once.
The application sends the authorization code along with the code_verifier (created in step 2.) to the authorization server (/oauth/token endpoint).
The authorization server verifies the code_challenge and code_verifier.
The authorization server sends to the application an ID Token and Access Token (and optionally, a Refresh Token). The Access Token contains user claims.
When the application wants to access a resource such as a WebApi it adds the Access Token containing user claims to the authorization header of a HttpClient request in the form of a Bearer token.

Headway Authentication

Identity Providers

To access resources via the Headway.WebApi the authentication server must issue a token to the user containing a RoleClaim called headwayuser and the users email. The application can then access further information about the user from the Headway.WebApi to determine what the user is authorised to do e.g. Headway.WebApi will return the menu items to build up the navigation panel. If a user does not have permission to access a menu item then Headway.WebApi simply wont return it.

Headway currently supports authentication from two identity providers IdentityServer4 and Auth0. During development you can toggle between them by setting IdentityProvider:DefaultProvider in the appsettings.json files for Headway.BlazorServerApp, Headway.BlazorWebassemblyApp and Headway.WebApi e.g.

  "IdentityProvider": {
    "DefaultProvider": "Auth0"
  },

NOTE: if implementing Auth0 you will need to create a Auth Pipeline Rule to return the email and role as a claim.

function (user, context, callback) {
 	const accessTokenClaims = context.accessToken || {};
	const idTokenClaims = context.idToken || {};
  const assignedRoles = (context.authorization || {}).roles;
  accessTokenClaims['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'] = user.email;
  accessTokenClaims['http://schemas.microsoft.com/ws/2008/06/identity/claims/role'] = assignedRoles;
  idTokenClaims['http://schemas.microsoft.com/ws/2008/06/identity/claims/role'] = assignedRoles;
  return callback(null, user, context);
}

Blazor WebAssembly

UserAccountFactory converts the RemoteUserAccount into a ClaimPrincipal for the application
AuthorizationMessageHandler attaches token to outgoing HttpClient requests

Blazor Server

InitialApplicationState gets the access_token, refresh_token and id_token from the HttpContext after authentication and stores them in a scoped TokenProvider
The scoped TokenProvider is manually injected into each request class and the bearer token is added to the Authorization header of outgoing HttpClient requests

WebApi

Accessible only to authenticated users carrying the headwayuser role claim and controllers are embelished with the [Authorize(Roles="headwayuser")] attribute.
A further check is made on every request using the email claim to confirm the user has the relevant Headway role or permission required to access to resource being requested.

Other Implementation Examples for Identity Providers

For IdentityServer4 see blazor-solution-setup.
For Auth0 see blazor-auth0.

Tracking Changes

When using Entity Framework Core, models inheriting from ModelBase will automatically get properties for tracking instance creation and modification. Furthermore, an audit of changes will be logged to the Audits table.

    public abstract class ModelBase
    {
        public DateTime? CreatedDate { get; set; }
        public string CreatedBy { get; set; }
        public DateTime? ModifiedDate { get; set; }
        public string ModifiedBy { get; set; }
    }

To log changes ApplicationDbContext overrides DbContext.SaveChanges and gets the changes from DbContext.ChangeTracker. Capturing the user is done by calling ApplicationDbContext.SetUser(user). This is currently set in RepositoryBase where it is called from ApiControllerBase which gets the user claim from to authorizing the user.

Logging

Headway.WebApi uses Serilog for logging and is configured to write logs to the Log table in the database using Serilog.Sinks.MSSqlServer.

Send logs from the Client

The client can send a log entry request to the Headway.WebApi e.g.:

            try
            {
                var x = 1 / zero;
            }
            catch (Exception ex)
            {
                var log = new Log { Level = Core.Enums.LogLevel.Error, Message = ex.Message };

                await Mediator.Send(new LogRequest(log))
                    .ConfigureAwait(false);
            }

Logging is also available to api request classes inheriting LogApiRequest and can be called as follows:

            var log = new Log { Level = Core.Enums.LogLevel.Information, Message = "Log this entry..." };

            await LogAsync(log).ConfigureAwait(false);

Configure Logging

In the Serilog config specify a custom column to be added to the Log table to capture the user with each entry. To automatically log EF Core SQL queries to the logs, add the override "Microsoft.EntityFrameworkCore.Database.Command": "Information".

  "Serilog": {
    "Using": [ "Serilog.Sinks.MSSqlServer" ],
    "MinimumLevel": {
      "Default": "Information",
      "Override": {
        "Microsoft": "Error",
        "Microsoft.EntityFrameworkCore.Database.Command": "Information"
      }
    },
    "WriteTo": [
      {
        "Name": "MSSqlServer",
        "Args": {
          "connectionString": "Data Source=(localdb)\\mssqllocaldb;Database=Headway;Integrated Security=true",
          "tableName": "Logs",
          "autoCreateSqlTable": true,
          "columnOptionsSection": {
            "customColumns": [
              {
                "ColumnName": "User",
                "DataType": "nvarchar",
                "DataLength": 100
              }
            ]
          }
        }
      }
    ]
  },

More details on enriching Serilog log entries with custom properties can be found here. For Serilog enrichment to work loggerConfiguration.Enrich.FromLogContext() is called when configuring logging in Program.cs.

builder.WebHost.UseSerilog((hostingContext, loggerConfiguration) =>
                  loggerConfiguration.ReadFrom.Configuration(hostingContext.Configuration)
                                        .Enrich.FromLogContext());

Middleware is also added in Program.cs to get the user from the httpContext and push it onto the logging context for each request. The middleware must be added AFTER app.UseAuthentication(); so the user claims is available in the httpContext.

app.UseAuthentication();

app.Use(async (httpContext, next) =>
{
    var identity = (ClaimsIdentity)httpContext.User.Identity;
    var claim = identity.FindFirst(ClaimTypes.Email);
    var user = claim.Value;
    LogContext.PushProperty("User", user);
    await next.Invoke();
});

Authorization

The following UML diagram shows the ClaimModules API obtaining an authenticated users permissions which restrict the modules, categories and menu items available to the user in the Navigation Menu:

Page Layout

Page Rendering

Documents

Document

TabDocument

Document Validation

Headway documents use Blazored.FluentValidation where the <FluentValidationValidator /> is placed inside the <EditForm> e.g.

    <EditForm EditContext="CurrentEditContext">
        <FluentValidationValidator />

NOTE: Blazored.FluentValidation is used for client side validation only while DataAnnotation and Fluent API is used for server side validation with Entity Framework.

For additional reading see Data Annotations Attributes and Fluent API Configurations in EF 6 and and EF Core.

Components

Standard Components

Dropdown Components

Dropdown

The source for a standard dropdown is IEnumerable<OptionItem> and the selected item is bound to @bind-Value="SelectedItem".

DropdownEnum

DropdownComplex

Generic Components

Specialized Components

Communication Between Components

StateNotificationMediator

Linked Components

Fields can be linked to each other so at runtime the value of one can be dependent on the value of another. For example, in a scenario where one field is Country and the other is City, and both are rendered as dropdown lists. The dropdown list for Country is initially populated while the dropdown list for "City" remains empty. Only once a country has been selected will the dropdown list for City be populated, with a list of cities belonging to the selected country.

Making a Component Link Enabled

A link enabled component, such as Dropdown.razor, must inherit from DynamicComponentBase.
The component must inherit IStateNotification.
It must also call DynamicComponentBase.LinkFieldCheck() to obtain the value of the LinkedSource field.
Finally, if the backing field has any LinkedDependents the component must notify state has changed when its value changes.

Linking two DynamicFields in the same DynamicModel

In the target field's ConfigItem.ComponentArgs property add a LinkedSource key/value pair:
e.g. Name=LinkedSource;VALUE=[LINKED FIELD NAME]
At runtime, when the DynamicModel is created, linked fields will be mapped together in ComponentArgHelper.AddDynamicArgs(), so the target references the source field via it's LinkedSource property.

Propagating Linked DynamicFields across different DynamicModels

It is possible to link two DynamicFields in different DynamicModels. This is done using PropagateFields key/value pair:
e.g. Name=PropagateFields;VALUE=[COMMA SEPARATED LINKED FIELD NAMES]
Consider the example we have Config.cs and ConfigItem.cs where ConfigItem.PropertyName is dependent on the value of Config.Model.

Config.Model is rendered as a dropdown containing a list of classes with the [DynamicModel] attribute. ConfigItem.PropertyName is rendered as a dropdown containing a list of properties belonging to the class selected in Config.Model.

    [DynamicModel]
    public class DemoModel
    {
        // code omitted for brevity

        public string Model { get; set; }
        
        public List<DemoModelItem> DemoModelItems { get; set; }
        
        // code omitted for brevity
    }
    
    [DynamicModel]
    public class DemoModelItem
    {
        // code omitted for brevity
        
        public string PropertyName { get; set; }

        // code omitted for brevity
    }

To map the linked source DemoModel.Model to target DemoModelItem.PropertyName: \

In the DemoModel's ConfigItem for DemoModelItems, it's ConfigItem.ComponentArgs property will contain a PropagateFields key/value pair:
e.g. Name=PropagateFields;VALUE=Model
In the DemoModelItem's ConfigItem for PropertyName, it's ConfigItem.ComponentArgs property will contain a LinkedSource key/value pair:
e.g. Name=LinkedSource;VALUE=Model
At runtime, when the DynamicModel is created, the linked source DemoModel.Model will be propagated in ComponentArgHelper.AddDynamicArgs(), where the propagated args will be passed into the DemoModel.DemoModelItems's component as a DynamicArg whose value is the source field DemoModel.Model. The component for DemoModel.DemoModelItems inherit from DynamicComponentBase, which will map the linked fields together so the target references the source field via it's LinkedSource property.

Configuration

Administration

Database

Data access is abstracted behind interfaces. Headway.Repository provides concrete implementation for the data access layer interfaces. it currently supports MS SQL Server and SQLite, however this can be extended to any data store supported by EntityFramework Core.

Headway.Repository is not limited to EntityFramework Core and can be replaced with a completely different data access implementation.

Add the connection string to appsettings.json of Headway.WebApi.

Note Headway will know whether you are pointing to SQLite or a MS SQL Server database based on the connection string. This can be extended in DesignTimeDbContextFactory.cs to use other databases if required.

  "ConnectionStrings": {

    /* SQLite*/
    /*"DefaultConnection": "Data Source=..\\..\\db\\Headway.db;"*/
    
    /* MS SQL Server*/
    "DefaultConnection": "Server=(localdb)\\mssqllocaldb;Database=Headway;Trusted_Connection=True;"
    
  }

Create the database and schema using EF Core migrations in Headway.MigrationsSqlServer or MigrationsSqlite, depending on which database you choose. If you are using Visual Studio in the Developer PowerShell navigate to Headway.WebApi folder and run the following:

UML Diagrams

The following incredibly useful UML diagrams have been provided by @VR-Architect.

Blazor Server OnStart

ClaimModules API

Notes

Adding Font Awesome

Right-click the wwwroot\css folder in the Blazor project and click Add then Client-Side Library.... Search for font-awesome and install it.
For a Blazor Server app add @import url('font-awesome/css/all.min.css'); at the top of site.css.
For a Blazor WebAssembly app adding @import url('font-awesome/css/all.min.css'); to app.css didn't work. Instead add <link href="css/font-awesome/css/all.min.css" rel="stylesheet" /> to index.html.

EntityFramework Core Migrations

Migrations are kept in separate projects from the ApplicationDbContext. The ApplicationDbContext is in the Headway.Repository library, which is referenced by Headway.WebApi. When running migrations from Headway.WebApi, the migrations are output to either Headway.MigrationsSqlite or Headway.MigrationsSqlServer, depending on which connection string is used in Headway.WebApi's appsettings.json. For this to work, a DesignTimeDbContextFactory class must be created in Headway.Repository. This allows migrations to be created for a DbContext that is in a project other than the startup project Headway.WebApi. DesignTimeDbContextFactory specifies which project the migration output should target based on the connection string in Headway.WebApi's appsettings.json.

    public class DesignTimeDbContextFactory : IDesignTimeDbContextFactory<ApplicationDbContext>
    {
        public ApplicationDbContext CreateDbContext(string[] args)
        {
            IConfigurationRoot configuration
                = new ConfigurationBuilder().SetBasePath(
                    Directory.GetCurrentDirectory())
                       .AddJsonFile(@Directory.GetCurrentDirectory() + "/../Headway.WebApi/appsettings.json")
                       .Build();
            var builder = new DbContextOptionsBuilder<ApplicationDbContext>();
            var connectionString = configuration.GetConnectionString("DefaultConnection");
            if(connectionString.Contains("Headway.db"))
            {
                builder.UseSqlite(connectionString, x => x.MigrationsAssembly("Headway.MigrationsSqlite"));
            }
            else
            {
                builder.UseSqlServer(connectionString, x => x.MigrationsAssembly("Headway.MigrationsSqlServer"));
            }

            return new ApplicationDbContext(builder.Options);
        }
    }

Headway.WebApi's Startup.cs should also specify which project the migration output should target base on the connection string.

            services.AddDbContext<ApplicationDbContext>(options =>
            {
                if (Configuration.GetConnectionString("DefaultConnection").Contains("Headway.db"))
                {
                    options.UseSqlite(Configuration.GetConnectionString("DefaultConnection"),
                        x => x.MigrationsAssembly("Headway.MigrationsSqlite"));
                }
                else
                {
                    options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection"),
                        x => x.MigrationsAssembly("Headway.MigrationsSqlServer"));
                }
            });

In the Developer PowerShell window navigate to the Headway.WebApi project and manage migrations by running the following command:

Add a new migration:

dotnet ef migrations add UpdateHeadway --project ..\..\Utilities\Headway.MigrationsSqlServer

Update the database with the latest migrations. It will also create the database if it hasn't already been created:

dotnet ef database update --project ..\..\Utilities\Headway.MigrationsSqlServer

Remove the latest migration:

dotnet ef migrations remove --project ..\..\Utilities\Headway.MigrationsSqlServer

Supporting notes:

Create migrations from the repository library and output them to a separate migrations projects
https://medium.com/oppr/net-core-using-entity-framework-core-in-a-separate-project-e8636f9dc9e5
https://docs.microsoft.com/en-us/ef/core/managing-schemas/migrations/projects?tabs=dotnet-core-cli

Handle System.Text.Json Circular Reference Errors

Newtonsoft.Json (Json.NET) has been removed from the ASP.NET Core shared framework. The default JSON serializer for ASP.NET Core is now System.Text.Json, which is new in .NET Core 3.0.

Entity Framework requires the Include() method to specify related entities to include in the query results. An example is GetUserAsync in AuthorisationRepository.

        public async Task<User> GetUserAsync(string claim, int userId)
        {
            var user = await applicationDbContext.Users
                .Include(u => u.Permissions)
                .FirstOrDefaultAsync(u => u.UserId.Equals(userId))
                .ConfigureAwait(false);
            return user;
        }

The query results will now contain a circular reference, where the parent references the child which references parent and so on. In order for System.Text.Json to handle de-serialising objects contanining circular references we have to set JsonSerializerOptions.ReferenceHandler to IgnoreCycle in the Headway.WebApi's Startup class. If we don't explicitly specify that circular references should be ignored Headway.WebApi will return HTTP Status 500 Internal Server Error.

            services.AddControllers()
                .AddJsonOptions(options => 
                    options.JsonSerializerOptions.ReferenceHandler = ReferenceHandler.IgnoreCycles);

Configure ASP.Net Core use Json.Net

The default JSON serializer for ASP.NET Core is now System.Text.Json. However, System.Text.Json is new and might currently be missing features supported by Newtonsoft.Json (Json.NET).
I reported a bug in System.Text.Json where duplicate values are nulled out when setting JsonSerializerOptions.ReferenceHandler = ReferenceHandler.IgnoreCycles.

How to specify ASP.NET Core use Newtonsoft.Json (Json.NET) as the JSON serializer install Microsoft.AspNetCore.Mvc.NewtonsoftJson and the following to the Startup of Headway.WebApi:
Note: I had to do this after noticing System.Text.Json nulled out duplicate string values after setting ReferenceHandler.IgnoreCycles.

            services.AddControllers()
                .AddNewtonsoftJson(options => 
                    options.SerializerSettings.ReferenceLoopHandling = ReferenceLoopHandling.Ignore);

Acknowledgements

@VR-Architect - for providing incredibly useful UML Diagrams

Name		Name	Last commit message	Last commit date
Latest commit History 3,389 Commits
readme-images		readme-images
src		src
tests/Headway.Core.Tests		tests/Headway.Core.Tests
utilities		utilities
.gitignore		.gitignore
Headway.sln		Headway.sln
LICENSE		LICENSE
README.md		README.md

User	Headway Role	Indentity Provider RoleClaim
[email protected]	Admin	headwayuser
[email protected]	Developer	headwayuser

License

grantcolley/headway

Folders and files

Latest commit

History

Repository files navigation