-
Notifications
You must be signed in to change notification settings - Fork 230
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
Increase rate limit #253
Comments
Thanks! Could you explain the use case where you need higher limits? Or rather, we have the following limits right now:
Could you point out which one is too low in your opinion? You should be able to check which one it is that you’re hitting in your application. The main aspect in the reasoning behind these limits is that your email delivery either does work or does not. And it may take time. So there’s no point in trying to re-send an email yet again after just a few minutes if the previous email has not arrived yet. Apart from all that, you can disable throttling or rate limiting entirely, as described here. |
From my personal experience when onboarding a new company to our system people end up getting throttled after the first hour because all the employees of the office share the same IP. |
@runnermatthew Thanks, that’s certainly a valid point. Any idea how to solve this (other than temporarily disabling the feature during onboarding)? We could introduce an option like “has business customers (with multiple users/seats)” that affects rate limiting via IP address. Or we could add an alternative option like “maximum users/seats per customer”. But (a) that increases complexity and (b) in other cases you may not even know about (new) business customers with larger numbers of employees using your application if you are not actively onboarding them and you are not specifically monitoring for business customers (e.g. via email domains). If onboarding is the main problem, we could just increase the “burstiness” of the allowed usage, i.e. allow larger (short) spikes. If normal usage afterwards is the problem, however, we would need to relax IP address limits by a factor such as 10×. Perhaps this all simply shows that we cannot have a one-size-fits-all solution. Exposing every individual limit in a configuration is too much complexity, but I would be open to, say, three levels of strictness that you can pick from. |
The main issue we are seeing is that not everyone is registered inside of an hour. Relaxing IP address limits would help. Would it be possible to pass our own throttle identifier? |
You can disable throttling temporarily, and you can restrict it to single pages or actions in your application, e.g. by passing something like |
Of course, you could use these conditional throttle arguments passed to the constructor to whitelist IP addresses as well, by enabling throttling only when the client’s IP address is not one of your whitelisted IP addresses. |
@ocram Thank you for the additional suggestions. I think the best path forward for my project is to wrap your library, disable throttling in the constructor, and add throttling with our custom identifiers and throttling values in the wrapped method calls. Please confirm that directly calling Line 1736 in df16db9
|
Oh well, you’re right, of course. Sorry! The following change, available from You might have to provide up to three By the way, as mentioned above, wrapping the entire library, disabling throttling entirely and then adding your own throttling everywhere again shouldn’t be necessary, since you could also just disable throttling for sign ups and add your own there. |
@ocram That looks fantastic. Thank you! |
Necro'ing this topic. My suggestion would be to set throttling and rate limit settings at the start of Auth. Just pass an array with desired custom options. At the moment I need to increase default rate limit by 3x. How to do that is no easy way, just entirely disable throttle. |
how to increase resend confirmation email rate limit
The text was updated successfully, but these errors were encountered: