Skip to content
New issue

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

#

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

Already on GitHub? # to your account

Jump to bottom

Action based rate limiting #1865

Open
rmarronnier opened this issue Apr 13, 2024 · 2 comments · May be fixed by #1917
Open

Action based rate limiting #1865

rmarronnier opened this issue Apr 13, 2024 · 2 comments · May be fixed by #1917
Labels
feature request A new requested feature / option hacktoberfest Valid Issue for Hacktoberfest

Comments

@rmarronnier
Copy link
Contributor

To protect a web app against abusive connections / requests (sub DDOS scale) several layers can help (nginx, middleware), but stumbling on Rails future rate limiting , I'm quite jealous of the elegant DX of this solution.

I could clearly see this working in Lucky :

class SignIns::New < BrowserAction
  include Auth::RedirectSignedInUsers
  rate_limit to: 50, within: 10.seconds

  get "/sign_in" do
    html NewPage, operation: SignInUser.new
  end
end

I can't implement this right now, I'm just putting it out there as a starting point for discussion / inspiration.
@jwoertink jwoertink added feature request A new requested feature / option and removed bug labels Apr 14, 2024
@jwoertink
Copy link
Member

Yeah, I dig it. I think rails has an easy way to handle it with having their key/value store built-in now. I wonder how this would scale with postgres backed. Or would this feature require redis to be added in?

@rmarronnier
Copy link
Contributor Author

The best solution would be to rely on https://github.com/luckyframework/lucky_cache and let the user configure their preferred backend (redis, db, etc). That's what Rails ended up doing : rails/rails#50781

It would require implementing new store(s) for lucky_cache (redis for example). Caching for Avram might also benefit from it.

With a redis store added to lucky_cache, a dependency on a redis shard would be added (not an issue for redis-less users if the redis store is not used).

Again, I can't do the work right now, just putting down ideas :-)

@jwoertink jwoertink added the hacktoberfest Valid Issue for Hacktoberfest label Sep 30, 2024
russ added a commit to russ/lucky that referenced this issue Oct 6, 2024
@russ
Action based rate limiting.
a4bce2c 
Include the module and write a rate_limit method to define the limit.
The rate_limit_key method can be overridden if you want differeny key
logic.

Ref luckyframework#1865
@russ russ linked a pull request Oct 6, 2024 that will close this issue
Open
5 tasks
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
feature request A new requested feature / option hacktoberfest Valid Issue for Hacktoberfest
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Action based rate limiting. russ/lucky
2 participants
@jwoertink @rmarronnier