You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice to have a configurable rate limiting by IP address.
Something like:
Only allow an IP address to perform N requests per TIME_FRAME
e.g. Only allow an IP address to perform 2 requests per 1 hour
Note that the source IP address doesn't need to necessarily be the one that is doing the request to the faucet. Sometimes there are proxies or load balancers in between. In those cases, the X-Forwarded-For header could be used. So this should also be configurable, either the src IP of the request, or given a HTTP header.
As an initial version I think it's fine if the "IP database" keeps in memory and is dropped when the faucet is restarted.
Example of a config in YAML. (Could ofc be in a different format):
ipRateLimit:
maxRequests: 2
timeFrame: "1h"
sourceIPHeader: "X-Forwarded_For" # when not set, fall back to source IP of the HTTP request
Requests that are rate limited should get a HTTP/1.1 429 Too Many Requests as a response. The "Retry-After" response header could also be added, but it's just a nice to have.
The text was updated successfully, but these errors were encountered:
One fear was that individuals at hackathons are adversely affected by this. I'd say we can just add a support email beneath + a twitter handle - the hackathon co-ordinators can always reach us and we can send them a significant amount of test ETH for the event.
It would be nice to have a configurable rate limiting by IP address.
Something like:
e.g. Only allow an IP address to perform 2 requests per 1 hour
Note that the source IP address doesn't need to necessarily be the one that is doing the request to the faucet. Sometimes there are proxies or load balancers in between. In those cases, the
X-Forwarded-For
header could be used. So this should also be configurable, either the src IP of the request, or given a HTTP header.As an initial version I think it's fine if the "IP database" keeps in memory and is dropped when the faucet is restarted.
Example of a config in YAML. (Could ofc be in a different format):
Requests that are rate limited should get a HTTP/1.1 429 Too Many Requests as a response. The "Retry-After" response header could also be added, but it's just a nice to have.
The text was updated successfully, but these errors were encountered: