tip #44: Rate-Limit server functions
This commit is contained in:
@@ -0,0 +1,22 @@
|
||||
---
|
||||
tip_number: 44
|
||||
date: 2026-07-25
|
||||
category: security
|
||||
status: pending
|
||||
---
|
||||
|
||||
# Tip #44 — Rate-Limit server functions
|
||||
|
||||
**Date:** 2026-07-25
|
||||
**Category:** security
|
||||
**Source:** MC-Survival Wiki Daily Tip (cron @ 18:00 MESZ)
|
||||
|
||||
## Rate-Limit server functions
|
||||
|
||||
Apply a token-bucket rate limit per IP to anonymous server functions — for example 60 req/min on search and 10 req/min on write endpoints — and return a 429 with a Retry-After header when the limit is hit. It solves the abuse problem: search, item-pick, and any anonymous write endpoint are obvious targets for scripted abuse, scraping, and accidental loops. The signal is operational: TanStack Start server functions are publicly callable by default, and there is no rate limiting in front of them today, which is fine at 100 users and a real problem at 10,000. An in-memory bucket per server instance is the right starting point — switching to Redis later is a one-function change when multi-instance scale arrives.
|
||||
|
||||
## Implementation tips
|
||||
|
||||
1. Token-bucket per IP for unauthenticated routes. 60 req/min for search, 10 req/min for writes.
|
||||
2. In-memory bucket per server instance is fine for small scale; Redis later when multi-instance.
|
||||
3. Return 429 with Retry-After header — don't silently drop.
|
||||
Reference in New Issue
Block a user