Context
From Kasey's (approving) review of #209: #209 (review)
The rateLimit middleware (src/middlewares/rate-limit.ts) is a deliberately minimal abuse guard. Two of the review nits only matter once the API scales behind a load balancer / the limiter is reused on more endpoints — tracked here so they aren't lost:
- Expose limits via env vars.
MAX_BUCKETS, and the per-route windowMs / max (currently hard-coded at 20/min on bulk-texts) should be configurable through env.ts (with the current values as defaults) when the limiter is reused.
- Make the trusted-proxy assumption configurable.
clientKey assumes the last x-forwarded-for entry is appended by a trusted proxy (true on Azure App Service today). Behind a different topology (extra LB layers, no proxy) this needs a config knob — e.g. a trusted-hop-count or explicit trusted-proxy list, and/or an opt-out to key on socket address.
Not blocking anything today; the third review nit (log 429s) was addressed directly in #209.
Refs
Context
From Kasey's (approving) review of #209: #209 (review)
The
rateLimitmiddleware (src/middlewares/rate-limit.ts) is a deliberately minimal abuse guard. Two of the review nits only matter once the API scales behind a load balancer / the limiter is reused on more endpoints — tracked here so they aren't lost:MAX_BUCKETS, and the per-routewindowMs/max(currently hard-coded at20/minon bulk-texts) should be configurable throughenv.ts(with the current values as defaults) when the limiter is reused.clientKeyassumes the lastx-forwarded-forentry is appended by a trusted proxy (true on Azure App Service today). Behind a different topology (extra LB layers, no proxy) this needs a config knob — e.g. a trusted-hop-count or explicit trusted-proxy list, and/or an opt-out to key on socket address.Not blocking anything today; the third review nit (log 429s) was addressed directly in #209.
Refs