Make the rate limits actually run

[mircealungu]

None of the rate limits have ever been enforced

RATE_LIMITS keys every entry as api.<view>. The blueprint is declared as flask.Blueprint("endpoints", __name__) and merely assigned to a variable named api, so the real endpoint names are endpoints.*. Every lookup returned None:

'api.get_session'      -> None
'api.get_anon_session' -> None
'api.send_code'        -> None
'api.reset_password'   -> None
'api.add_user'         -> None
'api.add_basic_user'   -> None
'api.add_anon_user'    -> None

limiter.limit(...) was then handed None, threw, and a bare except Exception: pass swallowed it at startup. Nothing logged. On master, 15 rapid failed logins against an endpoint documented as 5 per minute:

status codes: [401, 401, 401, 401, 401, 401, 401, 401, 401, 401, 401, 401, 401, 401, 401]
any 429? False

Login brute-force protection, the password-reset throttle and the mass-registration cap are all inert in production, and have been since the file was added.

Correcting the prefix was not sufficient

With the names fixed, the limits registered but still didn't fire. limiter.limit(...) was being called for its side effect with the return value dropped, which registers the limit under a name (…sessions.get_session.get_session) that request dispatch never consults — dispatch resolves endpoints.get_session to the undecorated function still sitting in app.view_functions. The decorated function now goes back into the routing table, which is what finally produces a 429.

Worth noting because it's the second failure mode in a row where the call looked correct and did nothing.

Failing loudly

An endpoint name that doesn't resolve is now a RuntimeError at startup instead of a silent skip:

Rate limits configured for unknown endpoints: api.get_session. Endpoint names
are '<blueprint>.<view function>' and this app's blueprint is named 'endpoints'.

A typo taking the API down at boot is a much better failure than a typo quietly removing the login throttle. The whole value of this file is that a reader can believe it.

Two related fixes from the same read

• init_limiter ran before load_configuration_or_abort, so app.config.get("RATELIMIT_STORAGE_URI") always fell through to memory://. Configuring Redis could never have worked, and each gunicorn worker counted separately — meaning the real login limit, once enforced, is 5/minute per worker. It now runs after config load.
• The limiter is disabled under testing=True. The suite logs in far more than five times a minute as the same user from the same address, so enforcement has to be opt-in per test.

User search gets a limit

search_users accepts a full email address as a search key (#724). A single query only confirms an address the searcher already typed, but an unbounded endpoint would let a script sweep a wordlist to learn which addresses have accounts.

Keyed per session rather than per IP: these endpoints sit behind @requires_session, and a class behind one school NAT all adding each other at once is a lesson, not an attack. The key reads the session uuid the same way requires_session does but doesn't validate it — an invalid uuid gets rejected by the view anyway, and any opaque per-account token is fine for bucketing.

Testing

Four new tests in test_rate_limiting.py, each pinning a failure mode that actually occurred:

• every configured endpoint name resolves
• 15 rapid logins produce a 429
• 70 rapid searches produce a 429
• exhausting one session's search quota does not lock out a second session
• send_code is capped despite answering 200 to everything

Full API suite: 155 passed.

Full API suite: 152 passed.

The numbers, resized so a classroom can't reach them

The limits in this file had never met real traffic, because they never ran. Login was 20 per hour per IP, and a class of 60 behind one school NAT is a single bucket — most of the room would have been turned away with a 429 they could not clear except by waiting out the window. Schools behind NAT are the core user base, so enabling the limits as written would have hit them first and hardest.

Login and password reset are now charged only for requests the endpoint rejected. Correct sign-ins cost nothing. That single change decouples the ceiling from crowd size: a room of any size signing in normally never touches the limit, so the number can stay low enough to still mean something.

Endpoint	Was (per IP)	Now (per IP)	Charged for
get_session, get_anon_session	5/min, 20/hour	100/min, 1000/hour	rejected attempts only
reset_password (submit a code)	3/min, 10/hour	20/min, 200/hour	rejected attempts only
send_code (request a code)	3/min, 10/hour	5/hour per target address, plus 20/min, 200/hour per IP	every request
add_user, add_basic_user	100/hour	500/hour	all
add_anon_user	200/hour	200/hour (unchanged)	all
search_users	—	60/min, 600/hour per session	all

1000 failed attempts an hour from one address is not something a school produces; it is what one host sitting there guessing looks like.

send_code is the exception that proves the rule. It deliberately answers "OK" even for addresses that don't exist, so it can't be used to enumerate users — which means charging it on failures would charge it nothing, leaving the limit decorative and the endpoint loopable as an email bomb aimed at whoever owns the address, on our SMTP bill. Guessing surfaces (login, submitting a code) count failures; an endpoint whose success is the costly act counts everything.

What this does and doesn't buy

An IP bucket honestly caps exactly one thing: a single host hammering. Anyone willing to rotate addresses — residential proxies, an IPv6 /64 — walks around it no matter what the number is. The defence that actually stops distributed brute force is a per-account limit keyed on the email already present in /session/<email>, so that sixty students are sixty buckets while an attacker hammering one account stays capped regardless of how many addresses they own. That is not in this PR; it's the obvious follow-up, and it's the piece that would let the per-IP number stay generous forever.

send_code is also keyed on the address in its own route, not just on the caller. A per-IP number can't stop an email bomb, because the caller can move; the inbox can't. Five an hour to any one address, from anywhere, and nobody legitimate needs a sixth. The per-IP limit stays underneath as a backstop against spraying one message at each of many addresses.

add_anon_user deliberately keeps its old 200/hour. It hands its invite_code to User.create_anonymous, which accepts the argument and never validates it — so unlike the other two creation endpoints, invite codes are not a second line of defence there and this limit is the whole of it. Anonymous accounts need no email, which also makes them the cheapest thing to mass-create.

Still open

With 4 gunicorn workers and no shared store, every limit is silently multiplied by up to 4. This PR makes RATELIMIT_STORAGE_URI reachable for the first time (it was being read before the config was loaded), but nothing is on the other end of it yet, so the numbers above are per-worker.

Testing

Six tests, each pinning a failure mode that actually occurred — including the two directions this file had never been tested in at all:

• every configured endpoint name resolves
• 105 rapid login failures produce a 429
• 70 rapid searches produce a 429
• 60 legitimate logins from one address produce no 429 (the classroom case)
• 150 correct sign-ins do not consume the failure budget
• exhausting one session's search quota does not lock out a second session

Independent of #724, which carries no limits and is unaffected.

🤖 Generated with Claude Code

[github-actions]

ArchLens - No architecturally relevant changes to the existing views