Good morning,
I need to create a custom Audit Feature in order to store within a SQL Table all the modification made in my tables. I already create a custom Feature like this
public class AuditFeature : IPlugin
{
public void Register(IAppHost appHost)
{
OrmLiteConfig.InsertFilter = AuditInsert;
OrmLiteConfig.UpdateFilter = AuditUpdate;
}
private void AuditUpdate(IDbCommand command, object arg2)
{
//how to get here the request remote ip address and the username stored within session?
}
private void AuditInsert(IDbCommand command, object arg2)
{
//how to get here the request remote ip address and the username stored within session?
}
}
Using the OrmLiteConfig filter I’m able to get all Insert and Update notification, but I need to get two additional info: the request remote ip address and the username that is stored inside the session bag. How can I get that information within AuditUpdate and AuditInsert methods?
Last, but not least, I need also to record deleted records, and the OrmLiteConfig filters does not allow it.
My service stack version in 6.0.2, my apphost is a .net framework self hosted application. I know it’s very old, we plan to update everything in a couple of month.
In my apphost configure method? Mine is a .net framework selfhost app, is it too old to access that method? And what about the delete filter? Is this the right way to achieve my goal?
This is only needed for ASP .NET Core. In ASP .NET Framework you can use HostContext.TryGetCurrentRequest() to access the Request Context, in a self-hosted HttpListener you wont be able to access the Request Context via Singleton and therefore you wont be able to use these methods to access the Request Context.
There is no DeleteFilter. I also don’t think you should ever try to access the Request Context from a singleton, it’s fragile and not portable and will fail if you attempt to access it from outside a HttpRequest worker thread.
I wouldn’t try to use these filters, and instead create reusable extension methods that you’d explicitly call passing in the Request context and any info you want to capture about the DB operation, e.g:
So you are suggesting to avoid my initial idea and use an extension methods on each Insert/Update/Delete in order to get all the information easilly. It’s a huge work, but I think I will do it as you proposed.
Yeah it’s the only solution where you have full control and wont run into request context issues, if you’re doing it a lot your custom extension methods can be combined to both insert/update and save Audit info.