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
Currently, Go uses the library express-rate-limit to rate limit OTP generations. By default, this library uses an in-memory store to keep track of the number of hits per IP. But using an in-memory store is problematic because this store is not shared across processes or servers, so each server keeps track of their own hits separately. If a load balancer distributes a client's requests across multiple servers, then the client can in practice hit the endpoint at a rate several times above the specified limit.
To Reproduce
I tried making POST requests to go.gov.sg/api/login/otp 12 times in a row, and they all succeeded. But by right it should fail after the 5th request (as it does on staging), because the current specified rate limit is 5 per minute. This happens because we currently have multiple servers for production, but only a single server for staging.
Solution
Switch the store to redis. This is also recommended by the authors of express-rate-limit.
Describe the bug
Currently, Go uses the library
express-rate-limit
to rate limit OTP generations. By default, this library uses an in-memory store to keep track of the number of hits per IP. But using an in-memory store is problematic because this store is not shared across processes or servers, so each server keeps track of their own hits separately. If a load balancer distributes a client's requests across multiple servers, then the client can in practice hit the endpoint at a rate several times above the specified limit.To Reproduce
I tried making POST requests to
go.gov.sg/api/login/otp
12 times in a row, and they all succeeded. But by right it should fail after the 5th request (as it does on staging), because the current specified rate limit is 5 per minute. This happens because we currently have multiple servers for production, but only a single server for staging.Solution
Switch the store to redis. This is also recommended by the authors of
express-rate-limit
.Documentation on store for
express-rate-limit
hereThe text was updated successfully, but these errors were encountered: