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
The main goal is to be able to set a different 'retry after' time. Additionally, I'd like the possibility to permanently ban certain IPs.
I propose having separate configuration parameters, something like this:
app.use(rateLimit({windowMs: 1000,// 1seglimit: 10,// 10 req per sec/// NEWretryAfter: 60*60*1000orasync(req,ip)=>number,// retry in 1hnotAllowed: ['123.123.1.1']orasync(req,ip)=>bool}):
Having the possibility to accept a function would make the system more flexible, especially in cases where the value varies depending on the user or IP.
Why
There are many cases where you might want to allow a certain number of requests within a specific time window. However, this doesn't necessarily mean that access should be regained immediately after that same time window.
The main problem is that if I set windowMs=1000 (1 second), users will be able to retry after just 1 second. But what I'd like to do is restrict this to a different time frame, such as 1 hour. Unfortunately, this isn't currently possible.
Additionally, I would like an option to block certain IPs. While I could create a separate middleware to check IPs and block them, it would be more suitable to leverage this library's existing advanced checks, such as proxy detection.
Alternatives
N/A
The text was updated successfully, but these errors were encountered:
The main goal is to be able to set a different 'retry after' time.
That's a good idea.
You could do the extended Retry-After part easily enough by setting headers: false and then having a custom handler() function that sets the headers, but it would advisory only, the library wouldn't enforce it.
Enforcing it is going to be a bit harder though, due to the current Store interface design. Let me think about that a bit more, though.
Another option is to create a couple of instances of express-rate-limit. The first one could allow 10 requests per second, and the second one could be 1000 per day or something like that. I know that's not quite what you asked for, but it could address some of the need.
Additionally, I'd like the possibility to permanently ban certain IPs.
I'm somewhat against the idea of permanently blocking IPs because most people are on dynamic IPs that change over time, so the blocks end up applying to people unrelated to the initial abuse.
Additionally proxies have legitimate uses, so I feel like blocking them outright throws out the good with the bad, and it is also getting farther away from the intended purpose of this library.
(Also, I've personally had my IP mislabeled as a proxy for the dumbest of reasons, and it took months to resolve. During that time, all kinds of things just didn't work, including my wifi garage door opener and some government websites.)
Sorry for the late reply, but you can block certain IPs if you really need to, using the skip option. You can see an example of it being used as a blocklist here.
Description
Hello,
The main goal is to be able to set a different 'retry after' time. Additionally, I'd like the possibility to permanently ban certain IPs.
I propose having separate configuration parameters, something like this:
Having the possibility to accept a function would make the system more flexible, especially in cases where the value varies depending on the user or IP.
Why
There are many cases where you might want to allow a certain number of requests within a specific time window. However, this doesn't necessarily mean that access should be regained immediately after that same time window.
The main problem is that if I set
windowMs=1000
(1 second), users will be able to retry after just 1 second. But what I'd like to do is restrict this to a different time frame, such as 1 hour. Unfortunately, this isn't currently possible.Additionally, I would like an option to block certain IPs. While I could create a separate middleware to check IPs and block them, it would be more suitable to leverage this library's existing advanced checks, such as proxy detection.
Alternatives
N/A
The text was updated successfully, but these errors were encountered: