feat(api): Add per-IP rate limiting middleware to /v1/auth/login and /v1/auth/signup

[Emmyt24]

Description

crates/api/src/lib.rs::build_router applies a permissive CORS layer but no rate limiting whatsoever, anywhere. crates/api/src/auth.rs::login already takes care to return an identical error for 'no such user' and 'wrong password' to prevent account enumeration, but with zero throttling, an attacker can still attempt unlimited password guesses per second against any known email address. This ticket adds basic per-IP middleware-level rate limiting as a first line of defense; a more complete persistent lockout policy is tracked separately as one of the hard/complex issues.

Requirements and Context

• Add tower_governor (or tower-http's own rate-limit primitives if the team prefers staying within the already-depended-on tower-http, but tower_governor is the more common choice for per-IP limiting on axum/tower) as a new dependency scoped to crates/api.
• Apply a per-IP limit (propose something like 10 requests/minute, but justify your chosen figures in the PR description) specifically to /v1/auth/login and /v1/auth/signup, not the whole API.
• Ensure the limiter correctly identifies the client IP behind a proxy consistent with the existing crate::audit::client_ip header-parsing convention (X-Forwarded-For then X-Real-IP) rather than defaulting to the immediate TCP peer address, which would be the load balancer's IP in production.

Suggested Execution

Branch: feat/api/auth-rate-limiting-middleware

Implement Changes

• Add the rate-limiting layer in crates/api/src/lib.rs::build_router, scoped only to the auth routes (e.g. via a nested Router with its own .layer(...), merged into the main router).

Test and Commit

• login_is_rate_limited_after_the_configured_threshold_per_ip.
• signup_is_rate_limited_after_the_configured_threshold_per_ip.
• rate_limit_is_scoped_per_ip_not_global (two distinct simulated client IPs each get their own budget).
• unrelated_routes_are_not_rate_limited_by_the_auth_layer.
• Run cargo test -p octo-api locally before committing.

Example Commit Message

feat(api): add per-IP rate limiting to the login and signup routes

Neither login nor signup had any request throttling, allowing unlimited
password-guessing attempts per second against any known email address
despite the enumeration-safe error message. Adds per-IP rate limiting scoped
to just these two routes as a first line of defense.

Guidelines

• Scope the limiter narrowly to the auth routes — do not rate-limit the whole API in this PR, since wallet/withdrawal/sponsor routes have their own distinct throttling needs better addressed by the separate persistent-lockout hard issue.
• Make sure the client-IP extraction matches the existing X-Forwarded-For/X-Real-IP convention already used in crates/api/src/audit.rs::client_ip, so behavior is consistent across the codebase.
• Reference this issue with Closes #<issue-number> in the PR description.

[YfengJ]

Hi maintainers, I would like to be considered for this FWC26 issue.

If assigned, I would keep the scope narrow: add per-IP throttling only for /v1/auth/login and /v1/auth/signup, reuse the project's existing X-Forwarded-For / X-Real-IP client-IP convention, avoid changing unrelated routes, and add focused octo-api coverage for login, signup, per-IP isolation, and an unrelated route staying unthrottled.

I will wait for explicit assignment before cloning, coding, or opening a PR.

[Lansa-18]

Hi @Emmyt24, I'd like to work on this.

I'll add tower_governor scoped to crates/api, apply per-IP rate limiting on a nested router containing only /v1/auth/login and /v1/auth/signup (leaving the rest of the API untouched), and wire IP extraction to match the existing X-Forwarded-For/X-Real-IP convention in crates/api/src/audit.rs::client_ip rather than the raw TCP peer address. I'll justify the chosen rate limit figures in the PR description.

Tests will cover: rate limiting triggers after the threshold per IP, limits are per-IP not global (two distinct IPs each get their own budget), and unrelated routes are unaffected. I'll run cargo test -p octo-api clean before opening the PR.

[grantfox-oss]

🦊 GrantFox — @Lansa-18 has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #105)
2. Your PR will be reviewed by the Octo-Protocol-org maintainers

Good luck! Track your progress on GrantFox.

[Lansa-18]

@Emmyt24 While going through the codebase, I found that main currently doesn't compile. Running:

cargo check --workspace

reports multiple errors across octo-store, octo-api, and octo-ingest, including duplicate function definitions, missing imports, calls to store methods that don't exist, an arity mismatch, and references to out-of-scope locals.

I also found a few additional issues:

• Four migrations share the 0008 version, causing sqlx::migrate! to fail.
• The RequestBodyLimitLayer is applied before the routes, so the 64 KiB request body limit isn't actually enforced.
• /v1/wallets/:id/webhooks/:endpoint_id/deliveries is registered twice, which causes Axum to panic when building the router.
• cargo test --all-targets can't run because Cargo.lock pins wiremock 0.6.5, which requires the Edition 2024 manifest format and isn't compatible with Cargo 1.84.1.

With the repository in its current state, I can't reliably build, test, or verify changes before opening PRs.

How would you like to proceed? Would you prefer that I wait until these issues are resolved or you have something else in mind?

Would be expecting your feedback. Thank you.