- ABP Framework version: v5.3.3
- UI type: Angular
- DB provider: EF Core
- Tiered (MVC) or Identity Server Separated (Angular): no
The documentation states that audit logging for get requests is turned off by default and can be turned on by setting the IsEnabledForGetRequests property of the AbpAuditingOptions object. However, if I look in my AbpAuditLogActions table, I have over 100K entries for various Get requests even though I have not set the IsEnabledForGetRequests property (see pic below). We have added an IgnoredUrl to AbpAspNetCoreAuditingOptions to get rid of some of the auditing records for hangfire which were cluttering up the tables.
What do I need to get rid of these audit logs for Get requests? I do not want these recorded.
Configure<AbpAspNetCoreAuditingOptions>(options =>
{
options.IgnoredUrls.Add("/hangfire/stats");
});
5 Answer(s)
-
0
Hi,
If you wouldn't like to record them you can disable this feature. Could you check here, please?
Regards.
-
0
This is not the answer to the question I asked. The logging I am asking about is in the AbpAuditLogActions table, it is not the entity logs.
According to your documentation https://docs.abp.io/en/abp/latest/Audit-Logging, the audit logging should be turned off for Get requests by default. I enable it using the property IsEnabledForGetRequests if I want to turn it on. I have not set that property, yet I am seeing audit log records for Get requests in the AbpAuditLogActions table.
-
0
An audit log action is typically a controller action or an application service method call during the web request. One audit log may contain multiple actions.
See: https://docs.abp.io/en/abp/latest/Audit-Logging?_ga=2.179751270.374253941.1662735671-1555045873.1662735669#audit-log-object
In other words, even if
IsEnabledForGetRequestsisfalse, more than one method can be called in POST(or etc.) requests and they are recorded in theAbpAuditLogActionstable. We can understand theGETrequest from theMethodNameaccording to the convention, but I don't believe this is the right approach for this situation. Maybe it will work more logically and properly to enable/disableAuditLogActionInfocompletely.What are your views on this? Would something like this meet your requirements?
-
0
I would be Ok with an option to enable/disable AuditLogActionInfo entirely. I have yet to find a use-case where we use the data in this table. So far, the AuditLogInfo and Entity*ChangeInfo tables have provided all the data we need.
-
0
Thanks for sharing your thoughts. I opened an issue.
See: https://github.com/abpframework/abp/issues/13995
Have a nice day!
