duration vs blockDuration

I’m not understanding the relationship between duration and blockDuration. Using the example “Login endpoint protection” in the wiki if I set my RateLimiterRedis configuration as:

const limiterConsecutiveFailsByUsernameAndIP = new RateLimiterRedis({
  storeClient: redisClient,
  keyPrefix: 'login_fail_consecutive_username_and_ip',
  points: 5,
  duration: 60 * 60 * 24 * 90, // Store number for 90 days since first fail
  blockDuration: 30
});

after 5 failed login attempts I’m locked out for 90 days-- the calculated retrySec is ~ 7776000 and any subsequent login attempts are blocked (until I delete my redis keys). I’m purposely setting the blockDuration to 30 (i.e. 30 seconds) for testing. Once it’s working as expected I’ll change to 1 hour (60 * 60) or something reasonable.

How do these 2 settings work together? For testing and understanding how this works I’ve set duration to 60 and blockDuration to 30, but only duration seems to matter and I reset 60 seconds after the first failed attempt. Once max points have been consumed in duration that appears to be it. How does blockDuration matter at all?

[hburrows]

@animir That works. Thanks!! Feel free to close this issue. Hopefully, I helped lower the barrier for the next user. Thanks for this great library and your outstanding support maintaining it.

[animir]

@hburrows You’re right, good catch. It never reaches consume, since get returns remainingPoints === 0 and 429 error.

We can check consumedPoints instead of remaining I’ve modified the example

  if (resSlowByIP !== null && resSlowByIP.consumedPoints > maxWrongAttemptsByIPperDay) {
    retrySecs = Math.round(resSlowByIP.msBeforeNext / 1000) || 1;
  } else if (resUsernameAndIP !== null && resUsernameAndIP.consumedPoints > maxConsecutiveFailsByUsernameAndIP) {
    retrySecs = Math.round(resUsernameAndIP.msBeforeNext / 1000) || 1;
  }

In this case it reaches one more consume and blocks it for blockDuration seconds. So all next get calls returns it as expected