Audit.NET | extensible framework to audit executing operations | Model View Controller library

O.K. I had not gone all the way through the docs. This my failure to RTFM.

I needed to install Audit.EntityFramework.Core on Persistence and change my DbContext to AuditDbContext. It is simple as that.

This was fixed on the latest Audit.NET.AzureCosmos version.

Issue: https://github.com/thepirat000/Audit.NET/issues/434

The problem was because the Audit.NET.AzureCosmos library previoulsy used Microsoft.Azure.DocumentDB.Core which was coupled to Newtonsoft.Json, but Audit.NET targeting .NET 5.0 uses System.Text.Json, so the JsonExtensionData and other attributes required on the AuditEvent were not taken into account.

Now when targeting .NET Standard 2.0 or .NET 5.0, the new client library Microsoft.Azure.Cosmos is used, and a custom serializer is set so the serializarion is handled by the default serialization mechanism from Audit.Core.Configuration.JsonAdapter

A change could be requested here for the Azure Cosmos data provider to allow building the container name with a delegate function that takes the AuditEvent as a parameter.

Similar to other data providers, like the SQL Server data provider.

So you could setup like this:

Looks like you're asking for an opinion, in that case I would strongly recommend a document oriented DB.

CosmosDB could be a great option since it supports SQL queries.

There is an extension to log to CosmosDB from Audit.NET: Audit.AzureCosmos

A sample query:

That's because the middleware can only access the response body already serialized as a byte array, so it's only decoded as string.

On the other hand, the action filter can access the object before it's written to the response stream, so if you also add it to the pipeline, the audit event for the requests reaching an action method, will look like what you're expecting.

For example, on your Startup class:

You should use the provided middleware in order to get the response headers, since most of the response headers are added on Result Filters which executes after the Action Filters, and the AuditApiGlobalFilter is an Action Filter.

The recommended approach is to configure both the action filter and the middleware so you get specific information for the action and also any information added afterwards such as the response headers. Also, including the middleware will allow to audit requests that does not reach a controller/action.

So just add the following to your startup:

What about using LogRequestIf which takes an HttpRequest as parameter:

You have at least two options

If you can map the audit log table to an Entity Framework DbContext (it could be the same DbContext you are auditing or a different one), then you could use the EntityFramework Data Provider instead of the SQL Data Provider.

For example, assuming you have an AuditLog table mapped to a DbContext:

The problem is that you can't set more than one default data provider to save the events.

So the second time the Audit.Core.Configuration.Setup().UseEntityFramework() is called, it will override the default data provider previously configured.

But you can use the override of .UseDbContext() that provides a way to set the Audit DbContext to use on a per-event basis.

So maybe you could have something like this: