feat(ui): Show the events behind a blocked IP#83
Merged
Conversation
The blocked-IP list showed only that an address was blocked and a one-line reason, with no way to see the requests that led there, and the security events table hid each event's message and user agent even though the backend recorded them. An operator could not tell a false positive from a real attacker. Any blocked IP, and any row in the events table, now opens a per-IP trace of its recorded events, each showing the path, status, user agent, and message. The events that drove an auto-block are visible where the block is.
Code Review SummaryThis PR implements a trace view for security events, allowing operators to audit the specific requests that led to an IP being blocked. This feature significantly enhances the observability of the security layer and helps in identifying false positives. 🚀 Key Improvements
💡 Minor Suggestions
|
![sourceant[bot]](https://avatars.githubusercontent.com/in/1161781?s=60&v=4){kind=small}
| </td> | ||
| <td>{{ event.status_code || "-" }}</td> | ||
| <td class="actions-cell"> | ||
| <button |
There was a problem hiding this comment.
Icon-only buttons should include an aria-label attribute to provide a clear description for screen reader users, as the title attribute is not always sufficient for accessibility.
Suggested change
| <button | |
| <button | |
| class="btn btn-icon btn-sm" | |
| title="View this IP's events" | |
| aria-label="View events for this IP" | |
| @click="showIPTrace(event.source_ip)" | |
| > | |
| <i class="pi pi-history" /> | |
| </button> |
| loadingTrace.value = true; | ||
| try { | ||
| traceEvents.value = await securityStore.fetchEventsByIP(ip); | ||
| } catch (e: any) { |
There was a problem hiding this comment.
When an API error occurs, closing the trace dialog or explicitly handling the error state in the UI prevents the user from seeing a misleading 'Empty' state.
Suggested change
| } catch (e: any) { | |
| } catch (e: any) { | |
| showTraceDialog.value = false; | |
| notifications.error("Failed", e.response?.data?.error || "Failed to load events for this IP"); |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
An operator could see that an IP was blocked and a one-line reason, but not the requests that led there: the blocked-IP list had no drill-down, the per-IP events endpoint went unused, and the events table hid each event's message and user agent. So a false positive was indistinguishable from a real attacker.
Every blocked IP, and every row in the events table, now opens a trace of that IP's recorded events, each showing path, status, user agent, and message.
Pairs with the agent-side fix that stops blocking legitimate clients and records why each block happened: flatrun/agent#176.