Align audit events endpoint with repository and do not require after

[wilkinsona]

Following on from #11331, I think we should remove the requirement for after from the audit events endpoint. To do so, I think we can remove AuditEventsEndpointWebExtension and then update the tests and documentation accordingly.

[wilkinsona]

We should consider what, if anything, should change in the JMX extension too.

[vpavic]

I've already expressed a somewhat related concern in #11331 (comment), which I think is even more of a problem with a web endpoint.

While allowing all nulls being passed to AuditEventRepository#find can be justified by the fact that it's an internal API and that one should know what they're doing while consuming it, I really don't think that it should be possible to hit /actuator/auditevents without parameters and have the entire repository dumped into a JSON.

[wilkinsona]

While limiting the size of the response may be a reasonable goal (I'm not totally sure that it is given who will be using the endpoint), I am sure that requiring the after parameter is not the answer.

As I've pointed out before, if someone wants to be malicious they can simply pass an after parameter that's decades in the past and dump the entire repository to JSON. Furthermore, requiring after places an unnecessary burden on anyone who wants to retrieve all the events, or wants to retrieve all the event of a particular type or for a particular principal as they now have to specify after too.

If we really think there's a need to restrict the response then the endpoint could require at least one of after,principal, or type, alternatively the endpoint or repository could enforce a (configurable) limit for the number of events that will be returned.

[snicoll]

FTR, I am with you with everything.

the endpoint or repository could enforce a (configurable) limit for the number of events that will be returned.

InMemoryAuditEventRepository has already a default capacity of 1000 (the one of the trace repository is 100 for the record). So it is already limited. IMO we should execute this one with a hint that users can configure the max number of results if necessary.

[vpavic]

InMemoryAuditEventRepository has already a default capacity of 1000 (the one of the trace repository is 100 for the record). So it is already limited. IMO we should execute this one with a hint that users can configure the max number of results if necessary.

I really think that InMemoryAuditEventRepository shouldn't be used as an argument when considering AuditEventRepository API as it's not a production grade implementation IMO. Its storage capabilities are limited and unless you don't want it to be a memory hog you need limit its capacity, and more importantly, it's not appropriate for use in a clustered environment for obvious reasons.

I've always used own AuditEventRepository implementation backed by a relational database in production, and this easily holds tens of thousands of audit events. So it's a problem if someone hits the endpoint without parameters and dumps all that data into a JSON, which also puts strain on the datababse.