Azkabahn Posted April 4, 2018 Report Share Posted April 4, 2018 Hi, I would like to propose to split auditing table in the backend into two tables. Not sure if other customers complain or have a huge load on PasswordState, but I tend to see that such feature would be beneficial. We have a lot of integration with CI/CD (Continuous integration / continuous delivery) tools via API and WinAPI. I am aware of the flag (PreventAuditing) that can be appended to the API calls in order not to leave traces in the audit log. I must say this should not be an option at all it's very complicated to do forensics or analyze if someone scraped all the password list with such flag. This leaves to another point. By having regular logs and API logs in one table, it reflects on UI performance. Also, what is the point for a regular user to see in the "recent activity grid" logs about API calls? Probably none, a user just want to have a glimpse into what's going on. Knowledge and understanding of what is API, in general, indicates that a person has a technical background. This means he/she will know where or how to find audit logs regarding API. Link to comment Share on other sites More sharing options...
support Posted April 4, 2018 Report Share Posted April 4, 2018 Hello, Thanks for the feedback, and if we receive interest from customers on this request, we will definitely look into it. We also recommend reviewing all your API scripts, because if you are returning all records and then looping through them, then this would explain your volume of auditing records. Instead, you should be using the search capabilities included in the API. Regards Click Studios Link to comment Share on other sites More sharing options...
support Posted April 4, 2018 Report Share Posted April 4, 2018 Thinking about this a little more, we don't think this would be a great deal of work - maybe 2 to 3 days. We would need to consider options for sending API Auditing data to syslog servers as well, but our main concern is the amount of API auditing records you currently have - during the upgrade process, ideally we want to move records between tables. But if you have millions of rows, then this could cause a timeout issue and make the upgrade fail. We'll need to think about what's possible for this data migration, so upgrade processes are smooth for customers. Regards Click Studios Link to comment Share on other sites More sharing options...
support Posted August 27, 2018 Report Share Posted August 27, 2018 Hi Everyone, This feature is now implemented in build 8449, and this video shows a bit more detail on how to use this if you are interested: https://www.youtube.com/watch?v=8ijyQ9_FmS0 Regards, Support Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.