Repository navigation
Add track() API for custom event tracking - #360
Conversation
![aikido-pr-checks[bot]](https://avatars.githubusercontent.com/in/898896?s=60&v=4){kind=small}
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
| eventName, // name | ||
| buildRequestData(context), // request | ||
| getManagerInfo(), // agent | ||
| context != null ? context.getUser() : null, // user |
There was a problem hiding this comment.
need to format the user here I think? so that we don't include the usual heartbeat props?
| return; | ||
| } | ||
|
|
||
| if (currentContext.incrementTrackedEventCount() > MAX_EVENTS_PER_REQUEST) { |
There was a problem hiding this comment.
Let's trigger once per request? (the warning)
|
|
||
| @Test | ||
| void createAPIEvent_WithContextButNoUser_ReturnsCustomEventEventWithNullUser() { | ||
| // Arrange |
There was a problem hiding this comment.
let's get rid of these comments? doesn't add much value imo ^^
There was a problem hiding this comment.
Are also part of other existing test files, but will remove.
|
|
||
| `track` only works inside an HTTP request. If you call it in a background job or outside of a request, nothing gets sent and you'll see a warning in the console. | ||
|
|
||
| Each request accepts up to 25 tracked events. Any further calls within the same request are dropped and logged as a warning. |
There was a problem hiding this comment.
align with other custom event docs? (a bit more compact)
b061545 to
b616b2b
Compare
c2ea7ba to
f65225b
Compare
| // Events pile up while Aikido's API is slow or down, so cap memory use. add() drops events when full. | ||
| private static final int MAX_QUEUE_SIZE = 100; | ||
| private static final BlockingQueue<APIEvent> queue = new LinkedBlockingQueue<>(MAX_QUEUE_SIZE); |
There was a problem hiding this comment.
🟡 Medium - Bounded shared event queue lets tracked traffic suppress attack reporting and playbook counts
An unauthenticated client can repeatedly hit an application route that calls Track.track(...), such as the documented failed-login flow. The PR changes the shared AttackQueue to a 100-item queue that drops new entries when full, and both custom events and detected attacks use that same queue. Once the queue is saturated, later custom events and real attack reports are discarded, so Aikido stops counting them for dashboard visibility and playbook-based blocking until the backlog drains.
| // Events pile up while Aikido's API is slow or down, so cap memory use. add() drops events when full. | |
| private static final int MAX_QUEUE_SIZE = 100; | |
| private static final BlockingQueue<APIEvent> queue = new LinkedBlockingQueue<>(MAX_QUEUE_SIZE); | |
| private static final BlockingQueue<APIEvent> queue = new LinkedBlockingQueue<>(); |
More info - Reply on this comment to give feedback or ignore the issue.
b99eb96 to
d0cbadd
Compare
No description provided.