-
Notifications
You must be signed in to change notification settings - Fork 61
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
Block duration option for throttler #1660
Comments
This would mean that we also need to keep track of the timing for the block duration as a part of the ThrottlerGuard, right? Or are you thinking of implementing a secondary guard that goes with it? I understand the use case, especially in trying to keep bots away, just making sure I understand where you're going with how you want to implement this. Also, you may want to wait on a PR until after this one is merged in (I'll be doing it probably later today or this week, need to update the docs) as there are a lot of breaking changes on it due to the nature of the feature change |
Yes. This is a part of ThrottlerGuard. Actually, we count totalHits on the basis of I am willing to make a PR on this issue if is everything okay. |
I think I'd like to see a PR for this. Would you like to make it off the |
Oaky. That will be great. |
Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
Currently, when a user exceeds their request limit within a defined time window (
ttl
), their requests are blocked for a fixed duration tied to thettl
.The proposed feature would allow developers to tailor the duration of this block separately from the
ttl
. This means developers can fine-tune how long user requests are restricted after reaching their limit, providing more control and adaptability for different use cases in NestJS.Describe the solution you'd like
I've devised a way to improve the rate limiting feature in NestJS. We can introduce a new option called
blockDuration
when importing the ThrottleModule. If users choose not to specifyblockDuration
, the system will fall back to the default behavior, which relies on thettl
.Teachability, documentation, adoption, migration strategy
What is the motivation / use case for changing the behavior?
As we built our app, security was a top concern. To prevent bot attacks, we decided to allow only a certain number of requests 'n' within a time frame 't'. If users exceeded this limit, we'd block them for a day. It was our way of keeping the bots at bay and ensuring a safe user experience.
The text was updated successfully, but these errors were encountered: