Rate limit register and unregister

[juanfradb]

Summary

• add a dedicated per-IP limiter for /api/register and /api/unregister
• keep the register/unregister bucket separate from /api/notify
• add cleanup for the new keyed limiter
• update route tests and docs for the new rate-limit behavior

Security validation

Source/sink/control: unauthenticated /api/register and /api/unregister could be called repeatedly from one client IP and churn or grow the in-memory TokenStore without an HTTP rate limit. Both routes now share a per-IP limiter with 120/min and burst 100, while /api/health, /api/info, and /api/status remain unwrapped.

Original issue no longer reproduces:

• 100 /api/register requests from one IP produces 429

• 100 /api/unregister requests from one IP produces 429

• /api/health, /api/info, and /api/status still do not 429 under tested bursts

Refs #7

Tests

• cargo test rate_limited_after_hundred -- --nocapture
• cargo test other_endpoints_not_rate_limited_under_burst -- --nocapture
• cargo test health_endpoint_not_rate_limited_1000_burst -- --nocapture
• cargo test
• cargo fmt --check
• cargo clippy --all-targets -- -D warnings
• git diff --check

Summary by CodeRabbit

• New Features

  • Rate limiting now protects /api/register and /api/unregister endpoints with per-IP limits (120 requests/min, burst 100), returning HTTP 429 when exceeded

• Documentation

  • API reference updated to document rate-limiting behavior across all endpoints
  • Architecture and configuration documentation enhanced with detailed rate-limiter specifications

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: f37e6cbc-1ed6-43d0-8af2-c6df8235aac1

📥 Commits

Reviewing files that changed from the base of the PR and between 893e7e1 and 3671b48.

📒 Files selected for processing (7)

• docs/api.md
• docs/architecture.md
• docs/configuration.md
• src/api/rate_limit.rs
• src/api/routes.rs
• src/api/test_support.rs
• src/main.rs

---

Walkthrough

This PR introduces a dedicated per-IP rate limiter for /api/register and /api/unregister endpoints to isolate registration request quota from the existing /api/notify per-IP limiter. The limiter is configured at 120 requests per minute with a burst of 100, integrated via Actix middleware, and tested across existing and new test cases.

Changes

Register Endpoint Rate Limiting

Layer / File(s)	Summary
Rate Limiter Type & Configuration src/api/rate_limit.rs	RegisterIpLimiter newtype and constants REGISTER_IP_RATE_PER_MIN (120) and REGISTER_IP_BURST (100) are added for separate quota management.
Middleware Implementation src/api/rate_limit.rs	register_ip_rate_limit_mw middleware extracts client IP, checks rate limit, returns 429 on rejection, and fails closed with 500 on wiring/IP-extraction failure.
Server Initialization & Cleanup src/main.rs	Register-IP limiter is instantiated, keyed cleanup task is configured, rate/burst values are logged at startup, and limiter is registered in Actix app state.
Test Infrastructure & Quota src/api/test_support.rs	test_register_ip_quota() helper, TestAppComponents.register_ip_limiter field, and test app builders wire the register limiter into test applications.
Route Middleware Wiring src/api/routes.rs	/api/register and /api/unregister routes are wrapped with register_ip_rate_limit_mw via from_fn().
Rate Limiting Test Cases src/api/routes.rs	New tests verify 429 response after burst quota exhaustion for register and unregister endpoints on a fixed client IP.
Existing Test Updates - IP Header Addition src/api/routes.rs	All register/unregister test cases are updated to include Fly-Client-IP header for consistent rate limiter IP extraction.
Structural Test Comments & Whitelist Matrix src/api/routes.rs	Comments are updated to reflect new rate-limiting behavior; whitelist matrix test wiring provides register_ip_limiter.
API & Configuration Documentation docs/api.md, docs/architecture.md, docs/configuration.md	Documentation updated to describe per-IP rate limiting for register/unregister (separate from notify), HTTP status codes (429, 500), and middleware wiring.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Poem

A rabbit in a field of queues,
Said "Let's split the register groove!"
Per-IP bucketed nice and clean,
No more mixing in between.
Burst by burst, at 120 strong,
Tokens flow where they belong. 🐰

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: adding rate limiting to the /api/register and /api/unregister endpoints, which is the primary focus of the changeset.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[AndreaDiazCorreia]

Nice work, the implementation looks solid and covers the acceptance criteria from #7. Just one thing before merging: could you update CLAUDE.md to mention that /api/register and /api/unregister can now return 429 with the shared rate_limited_response body? Same style as the 403 whitelist exception that's already documented there. The absolute upper bound on TokenStore from the issue is a different threat model (botnet/multi-IP), so probably better as a separate follow-up. Otherwise LGTM.