Closed ylashin closed 1 month ago
Hi @ylashin
For this one, I think it may be a bit dangerous/tricky/risky to enable that by default (because of streamed contents that we don't want to consume, and possibly binary stuff or large chunks of data ...).
I wonder if it would be better to enable that as an "opt-in" mechanism for specific needs, for instance by explicitly adding some object to capture in the log event ...
This could look something like :
Context.AddToSerilogWebLogEvent("RequestContent", something, destructure: false)
(Context
being an HttpContext
or HttpContextBase
or something of this family, i.e. something that lives for the duration of the request and can store arbitrary objects in a dictionary )
And then, when generating the event at the end of the request, the module could look in there and enrich the event with the registered properties ...
This mechanism could then be used directly from a given Controller Action / WebForm page , or more generically, for instance in MVC or WebAPI ActionFilter
s / ExceptionFilter
s ...
Thank @tsimbalar , your suggestion would work fine but I was actually thinking of something like
ApplicationLifecycleModule.LogPostedFormData = LogPostedFormDataOption.Always;
ApplicationLifecycleModule.FilterPasswordsInFormData = true;
Currently the above logs posted form data only. My idea is to have another flag to log the full HTTP payload in certain cases (e.g. JSON content type and failed HTTP request)
This would be a welcome addition when working with WebAPI calls in dev, test and staging. Should be configurable to disable it through appsettings in a production transform. I guess the existiong Serilog functionality in .Destructure.ToMaximumStringLength(x) whould be in effect if POST payload is too big?
This project is no longer being maintained and we are going to archive the SerilogWeb Repositories.
see:
Is it by design that we it are able only to log FormData and not any other plain POST payload like JSON. I know it would be aweful to log binary data or stuff like that but maybe we can add some configurable filter on the content type of the request.
It would be nice if we can have logs of full payload of at least failed HTTP requests