Express middleware for IP-based rate limiting with flexible configuration options and multiple storage backends
Overall
score
96%
{
"context": "Evaluates whether the Express middleware uses express-rate-limit's async option resolvers to enforce plan-aware throttling, keyed per user and route, with custom 429 responses and a safe fallback path when plan resolution fails.",
"type": "weighted_checklist",
"checklist": [
{
"name": "Async limit",
"description": "Configures express-rate-limit with the `limit` option as an async function that resolves plan data per request and returns 6 for `X-Plan: pro` and 2 for the default path, handling promise rejections without skipping enforcement.",
"max_score": 30
},
{
"name": "Async keyGenerator",
"description": "Sets `keyGenerator` (or `identifier`) to an async function that combines the `X-User` header and request path so counters are isolated per user and route rather than using the default IP-based key.",
"max_score": 25
},
{
"name": "Custom handler",
"description": "Supplies a custom `handler` (or async `message`) option to return HTTP 429 with a JSON body containing plan name, a human-readable reason, and `retryAfterSeconds` derived from express-rate-limit metadata such as `req.rateLimit.resetTime`.",
"max_score": 25
},
{
"name": "Fallback plan",
"description": "Catches plan lookup failures and applies the default plan through express-rate-limit (limit 1 per 60s window) while marking responses with `X-Limit-Source: fallback`, ensuring the limiter still runs instead of short-circuiting.",
"max_score": 20
}
]
}Install with Tessl CLI
npx tessl i tessl/npm-express-rate-limitevals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
scenario-6
scenario-7
scenario-8
scenario-9
scenario-10