feat: share rate-limit counters across API instances

Aberta
  • Algo errado?
#581 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
express, postgresql, typescript
Domínio
backend, databases, security

Direção de pesquisa

Start with docs/production-operations.md and inspect the account notice limiters, flow_rate_limits, and the global per-IP limiter to understand how counters are stored and applied. The issue leaves the store, limiter scope, and failure behavior open, so first map those choices into a design note or ADR. Done means the design is recorded, limits are verified across multiple instances by a test, and the operations documentation is updated.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

P2 secure v1.0

Why

Every rate limiter and slow-down in the API uses the in-memory store of express-rate-limit or express-slow-down. Each instance counts on its own, so with N instances behind a load balancer a client whose requests spread across them gets up to N times each budget. docs/production-operations.md ("Running More Than One Instance") documents this and the workaround: route by client address, or limit at the proxy as well.

Routing by address does not help the account notice limits on POST /applications/account-notices, because they are keyed by application and user. An application can send up to N times its notice allowance however requests are routed.

The counters that bound guessing are already shared in Postgres (auth_failures, OTP codes, magic links, WebAuthn challenges, refresh rotation, the OAuth state record), so the gap is volume (OTP and magic link sends, notice spam, load), not account takeover. Split from #553, whose per-user key fix shipped in #567.

What

Decide and build a shared store for the limiters where per-instance counting matters:

  • Which limiters share. The account notice limiters and flow_rate_limits first. Whether the global per-IP limit and slow-down need it, or stay in memory to keep the hot path free of a database write.
  • Which store. Postgres needs no new service, since every deployment has it already. A Redis or Valkey store could be an option for large deployments, never a requirement.
  • Failure mode when the store is unreachable: fail open, fail closed, or fall back to memory, per limiter.
  • Window and cleanup for expired counters.

Related

The global per-IP limit counts the provider edge's /oidc/* calls against the browser's address. Look at it in the same design.

Done when

  • A design note or ADR records which limiters share, the store, and the failure mode
  • Shared limits hold across two or more instances, covered by a test that runs more than one
  • docs/production-operations.md is updated
Linguagem predominante
TypeScript
Estrelas
2
Forks
2
Merge médio
12h 23min
PRs com merge (30d)
109

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de fells-code/seamless-auth-api

Todas as issues de fells-code/seamless-auth-api

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.