skoruba / auditlogging Goto Github PK

Perhaps the intent is for the user to purge the logs every so often, but I usually like making my Primary Id's longs these days (BIGINT in SqlServer).

Do you think this might be worth it? If not, then just close this issue.

Hi @skoruba

Are you able to provide some additional explanation with regard to the following Extension Methods of the IAuditLoggingBuilder. Many of the Methods are self explanatory

I'm happy to contribute to the project in any way I can.

AddDefaultEventAction(this IAuditLoggingBuilder builder);

Not Sure what this does - omitting this from the builder event seemingly had no effect. Nor did setting UseDefaultAction to false as per below. The "Action" property of the AuditEvent was always populated with the same data.

  services.AddAuditLogging(
                options =>
                {
                    options.UseDefaultSubject = false;
                    options.UseDefaultAction = false;
                })

AddDefaultEventData(this IAuditLoggingBuilder builder);

No discernible difference when added or omitted

AddDefaultEventSubject(this IAuditLoggingBuilder builder);

No discernible difference when added or omitted. Also setting options.UseDefaultSubject = false; has not effect.

AddEventData<TEventSubject, TEventAction>(this IAuditLoggingBuilder builder)
            where TEventSubject : class, IAuditSubject
            where TEventAction : class, IAuditAction;

No Idea

FYI This project looks perfect for my requirements. I've been able to deploy a custom sink which publishes to a MessageQueue (RabbitMQ) and then in another Microservice I subscribe to the message queue and persist them to a SQL Database.

When utilizing this with other class library's netstandard2.0 is a more universal as it doesn't require the full core libaries.

I tried setting up AuditLogging in IdentityServer4.STS.Identity project and inject IAuditEventLogger in custom AuditEventSink. But it breaks on startup at app.UseIdentityServer().

at Skoruba.AuditLogging.Events.Http.HttpAuditSubject..ctor(IHttpContextAccessor accessor, AuditHttpSubjectOptions options)
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitConstructor(ConstructorCallSite constructorCallSite, RuntimeResolverContext context)
at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2.VisitCallSiteMain(ServiceCallSite callSite, TArgument argument)

Any plans to accomodate Identity server events to audit table?

sorry, I was supposed to post in the IdentityServer4.Admin repo :(

Sorry.
. Duplicate. Not sure how to delete

Hi there, just wondering if it would be possible to configure AuditLogger to use a NoSql document data store with the currently available configuration options?
E.g so I could just store the output JSON as a record that could be queried.

I've used Azure Storage tables in the past for audit logs and the log tail pattern, with good results
https://docs.microsoft.com/en-us/azure/storage/tables/table-storage-design-patterns#log-tail-pattern as it's cheap at scale.

AuditLogging would be perfect for this to do the heavy lifting.

System.Text.Json is available now. It has become part of ASP.Net Core, and can also be used with netstandard projects.

One of the benefits is improvement performance.

Maybe this is something you'd like to look into?

It is not possible to manually set the Source property of AuditEvent because of https://github.com/skoruba/AuditLogging/blob/master/src/Skoruba.AuditLogging/Services/AuditEventLogger.cs#L69-L80

The only way to set it, currently, is through configuration, but you cannot e.g. use it to set what class the log was generated in.