Key the application notice per-user limit on the canonical user id

Open
#553 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
Half a day
Newbie friendliness
55/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
postgresql, typescript

Research direction

Start with the applicationNoticeUserLimiter key generator in src/middleware/applicationNoticeRateLimit.ts, where the raw req.body.userId is used as the bucket key. Compare it with the user lookup that resolves the canonical user.id to see where case normalization fits. Done when case variants of one UUID share a bucket and the limiter store choice is documented or made configurable for multi-instance deployments.

Written by the indexing model from the issue text.

Description

P1 security v0.23

Problem

applicationNoticeUserLimiter in src/middleware/applicationNoticeRateLimit.ts keys on the raw req.body.userId. z.uuid() accepts upper-case UUIDs and the Postgres lookup is case-insensitive, so case variants of one id get separate buckets, up to the per-client cap. Both notice limiters use the in-memory store, so each additional API instance multiplies the limits.

Fix

  • key on userId.toLowerCase(), or on the resolved user.id after lookup
  • use the shared rate-limit store when more than one instance runs
Dominant language
TypeScript
Stars
2
Forks
2
Avg merge
11h 40m
Merged PRs (30d)
104

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from fells-code/seamless-auth-api

All issues in fells-code/seamless-auth-api

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.