PHP-Auth
PHP-Auth copied to clipboard
delight-im
Increase rate limit
Thanks!
Could you explain the use case where you need higher limits?
Or rather, we have the following limits right now:
- 75 attempts in the first hour and 1 attempt in the following hours per IP address, shared with any other operation that can be used to check if an account or an email address exists
- 1 attempt every 6 hours per account
- 8 attempts in the first week and 4 attempts in the following weeks per IP address
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.
75 attempts in the first hour and 1 attempt in the following hours per IP address, shared with any other operation that can be used to check if an account or an email address exists
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.
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 $_GET['route'] !== 'sign_up' to the constructor as the $throttling parameter. When you have disabled throttling this way, you could additionally add your own throttling again, using the mechanism provided by this library and described in the README – which needs your own identifiers. Does that make sense?
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 throttle works when I've disabled throttling in the constructor for your library. https://github.com/delight-im/PHP-Auth/blob/df16db9b2b7bde84bc4f076a89616d296e92db71/src/Auth.php#L1736 makes it look like that isn't the case.
Oh well, you’re right, of course. Sorry!
The following change, available from v8.3.0, should fix the problem:
https://github.com/delight-im/PHP-Auth/commit/7bce546defa2bec75485d4bf1d68b72cf311c489
You might have to provide up to three null values before the new argument to use the default values, but you can certainly wrap this in a helper method for convenience.
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.
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.
