feat(auth): make the registration rate limit configurable (BUNYIP-150) #222

Closed

nrupard wants to merge 549 commits from feat/bunyip-150-configurable-register-limit into main

nrupard commented

2026-06-24 22:13:42 +02:00

Owner

What

Make the /v1/auth/register rate limit configurable so the E2E suite can register disposable accounts without tripping the production anti-abuse cap. BUNYIP-150 follow-up.

Why

RateLimitConfig::REGISTRATION is hardcoded at 3/IP/hour. The mail-sink E2E flows register a disposable account per run; at 3/hour/IP that allows only ~3 E2E runs/hour from the CI runner before a 429 (already observed on staging).

Change

crates/bunyip-domain/src/config.rs: new Config.registration_rate_limit_max, read from REGISTRATION_RATE_LIMIT_MAX (default 3, positive-only), so production is unchanged when the var is unset.
bunyip-api/src/handlers/auth.rs: the register handler builds the limit from config.registration_rate_limit_max instead of the const (window stays 1h).

Staging will set REGISTRATION_RATE_LIMIT_MAX high (separate docker PR). Production leaves it unset -> stays at 3.

Verification

just check-container green (fmt + clippy + workspace lib tests).

Sequence

Merge this -> staging rebuilds :latest -> deploy with the docker PR that sets REGISTRATION_RATE_LIMIT_MAX on c-01 bunyip-api. Then the e2e mail-sink fix PR (#221) can run without the register 429.

🤖 Generated with Claude Code

## What Make the `/v1/auth/register` rate limit configurable so the E2E suite can register disposable accounts without tripping the production anti-abuse cap. BUNYIP-150 follow-up. ## Why `RateLimitConfig::REGISTRATION` is hardcoded at 3/IP/hour. The mail-sink E2E flows register a disposable account per run; at 3/hour/IP that allows only ~3 E2E runs/hour from the CI runner before a 429 (already observed on staging). ## Change - `crates/bunyip-domain/src/config.rs`: new `Config.registration_rate_limit_max`, read from `REGISTRATION_RATE_LIMIT_MAX` (default 3, positive-only), so production is unchanged when the var is unset. - `bunyip-api/src/handlers/auth.rs`: the register handler builds the limit from `config.registration_rate_limit_max` instead of the const (window stays 1h). Staging will set `REGISTRATION_RATE_LIMIT_MAX` high (separate docker PR). Production leaves it unset -> stays at 3. ## Verification `just check-container` green (fmt + clippy + workspace lib tests). ## Sequence Merge this -> staging rebuilds `:latest` -> deploy with the docker PR that sets `REGISTRATION_RATE_LIMIT_MAX` on c-01 bunyip-api. Then the e2e mail-sink fix PR (#221) can run without the register 429. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

nrupard added 1 commit

2026-06-24 22:13:42 +02:00

feat(auth): make the registration rate limit configurable (BUNYIP-150)

E2E / Playwright against deployment (pull_request) Failing after 52s

Details

Check / fmt + clippy + build + tests (pull_request) Successful in 4m28s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

ef75af8665

Registration is capped at 3/IP/hour (RateLimitConfig::REGISTRATION) as a production anti-abuse measure. That cap throttles the E2E suite, which registers disposable accounts for the email-driven flows (password-reset / magic-link / change-email): even one registration per run allows only 3 E2E runs/hour from the CI runner's IP before a 429.

Add a `registration_rate_limit_max` Config field read from `REGISTRATION_RATE_LIMIT_MAX` (default 3, so production is unchanged) and use it in the register handler instead of the hardcoded const. Staging sets it high so the suite is not throttled; the window stays 1 hour.

#BUNYIP-150

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>