Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Instrument fail2ban #655

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Instrument fail2ban #655

wants to merge 2 commits into from

Conversation

woahdae
Copy link

@woahdae woahdae commented Mar 7, 2024

Previously, if a request triggered a ban, there was no instrumentation for knowing the ban occurred.

This instruments bans under the ban.rack_attack notification.

@woahdae woahdae force-pushed the instrument-fail2ban branch 2 times, most recently from e3b7731 to 923ecd5 Compare March 10, 2024 05:05
Previously, if a request triggered a ban, there was no instrumentation
for knowing the ban occurred.

This instruments bans under the `ban.rack_attack` notification.
@woahdae woahdae force-pushed the instrument-fail2ban branch from 923ecd5 to d872acc Compare March 10, 2024 05:07
Comment on lines +20 to +21
request.env["rack.attack.matched"] ||= name
request.env["rack.attack.match_type"] ||= type
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note to self: this can be considered a breaking change since it alters the way rack-attack currently notifies about blocklist.rack_attack

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can look at this more closely tomorrow, but the reason for this change was that, without this, the request was first getting a match_type of :ban set in the environment as it was banned, then as the request was blocklisted, it was overridden here as :blocklist. I believe the blocklist should work the same as it did previously, definitely if the developer hasn't passed in the request (an awkward requirement for this to work), maybe in general. I could look at the test suite with this in mind if it's a concern.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just had some time to come back to this.

I opened this PR #656 with my concern about this. This gem is so widely used that I wouldn't like to change existing behavior (unless it's in a new major version). I'm wondering if we can keep the existing events + adding the new one :ban that you are introducing. Maybe we can achieve that by not modifying the request.env in https://github.com/rack/rack-attack/pull/655/files#diff-aa6124b2b316bd2edb9f054a2a3200ab0c12248c79f4bc30da5195122c949363R73 and instead passing another object to Rack::Attack.instrument ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants