--- phase: 24-public-access-infrastructure plan: 01 subsystem: infra tags: [rate-limiting, middleware, hono, typescript] # Dependency graph requires: [] provides: - createRateLimit(maxAttempts, windowMs) factory function in rateLimit.ts - Tiered rate limits on all public GET endpoints (browse: 120/min, detail: 60/min) - Backward-compatible rateLimit export (5 req/15 min, unchanged behavior) affects: [future public API endpoints, catalog enrichment, discovery feed] # Tech tracking tech-stack: added: [] patterns: - "Factory pattern for configurable middleware: createRateLimit(max, windowMs) returns middleware fn" - "Shared in-memory store for rate limiting with IP:path composite keys" - "Tiered rate limits: browse tier (120/min) vs detail tier (60/min)" key-files: created: [] modified: - src/server/middleware/rateLimit.ts - src/server/index.ts - tests/middleware/rateLimit.test.ts key-decisions: - "Use factory pattern for rate limiter to support different tiers without code duplication" - "Browse endpoints (list/search) get 120/min limit; detail endpoints get 60/min — same for auth and anon users per D-08" - "Rate limits placed before auth middleware to apply equally regardless of auth state" - "Keep original rateLimit export (5/15min) for OAuth/auth endpoints unchanged" patterns-established: - "Rate limit factory: createRateLimit(max, windowMs) — reuse for any new endpoint needing limits" - "Method guard in middleware: check c.req.method === 'GET' before applying rate limit" requirements-completed: [INFR-01] # Metrics duration: 8min completed: 2026-04-10 --- # Phase 24 Plan 01: Rate Limiter Factory and Tiered Public Endpoint Limits Summary **createRateLimit(max, windowMs) factory with browse (120/min) and detail (60/min) tiers applied to all public GET endpoints before auth middleware** ## Performance - **Duration:** ~8 min - **Started:** 2026-04-10T10:00:00Z - **Completed:** 2026-04-10T10:08:00Z - **Tasks:** 2 - **Files modified:** 3 ## Accomplishments - Refactored single-tier rateLimit into createRateLimit factory supporting configurable limits - Original rateLimit export preserved with identical behavior (5 req/15 min, same error message) - Added 11 tests total (6 existing + 5 new factory tests) — all pass - Applied browseTier (120/min) to /api/global-items list and /api/tags GET routes - Applied detailTier (60/min) to /api/global-items/:id, /api/setups/:id/public, /api/users/:id/profile GET routes ## Task Commits Each task was committed atomically: 1. **Task 1: Refactor rateLimit.ts to factory pattern and extend tests** - `afab817` (feat) 2. **Task 2: Apply tiered rate limits to public GET endpoints in index.ts** - `5619016` (feat) ## Files Created/Modified - `src/server/middleware/rateLimit.ts` - Added createRateLimit factory; rateLimit delegates to factory; _resetForTesting unchanged - `src/server/index.ts` - Import createRateLimit; add browseTier/detailTier instances; apply to 5 public GET endpoint groups before auth middleware - `tests/middleware/rateLimit.test.ts` - Added createRateLimit factory describe block with 5 new test cases ## Decisions Made - Factory uses the same error message as the original ("Too many attempts. Try again later.") to preserve backward compatibility for existing tests - Import order follows Biome's organized-imports rule (auth.ts before rateLimit.ts alphabetically within middleware group) ## Deviations from Plan None - plan executed exactly as written. The only minor adjustment was error message consistency: the plan's code sample used "Too many requests." but the existing tests asserted "Too many attempts." — used the existing message to maintain backward compatibility without changing existing test expectations. ## Issues Encountered - Pre-existing test failures in storage.service tests (15 failing, 7 errors) unrelated to rate limiting — confirmed pre-existing before changes via git stash verification. Logged as out-of-scope. ## User Setup Required None - no external service configuration required. ## Next Phase Readiness - createRateLimit factory available for any new public endpoints added in future plans - All public GET endpoints now have abuse protection - Auth middleware flow unchanged — public endpoints remain unauthenticated, rate-limited only --- *Phase: 24-public-access-infrastructure* *Completed: 2026-04-10*