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

Block duration option for throttler #1660

Closed
1 task done
asif-jalil opened this issue Sep 4, 2023 · 5 comments
Closed
1 task done

Block duration option for throttler #1660

asif-jalil opened this issue Sep 4, 2023 · 5 comments

Comments

@asif-jalil
Copy link
Contributor

asif-jalil commented Sep 4, 2023

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

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 the ttl.

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 specify blockDuration, the system will fall back to the default behavior, which relies on the ttl.

Teachability, documentation, adoption, migration strategy

@Module({
  imports: [
    ThrottlerModule.forRoot({
      ttl: 5,
      limit: 3,
      blockDuration: 3600
    }),
  ],
})
export class AppModule {}

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.

@jmcdo29
Copy link
Member

jmcdo29 commented Sep 4, 2023

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

@asif-jalil
Copy link
Contributor Author

Yes. This is a part of ThrottlerGuard. Actually, we count totalHits on the basis of ttl. At this point, we can change it to blockDuration .

I am willing to make a PR on this issue if is everything okay.

@jmcdo29
Copy link
Member

jmcdo29 commented Sep 4, 2023

I think I'd like to see a PR for this. Would you like to make it off the feat/mutliple-throttlers branch, as that's the current 5.0.0 target? Just to make sure you take into account the changes that are coming from it

@asif-jalil
Copy link
Contributor Author

Oaky. That will be great.

@asif-jalil
Copy link
Contributor Author

#1668

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

No branches or pull requests

2 participants