Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

A caller cannot see their own usage

Cerrado
  • ¿Algo no está bien?
#513 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 3 días

@sparkysolutions10-pixel ya está trabajando en esto.

Desde el 19/10/2026.

  • #568 de @sparkysolutions10-pixel — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
api, authentication

Línea de trabajo

Read src/api/auth.ts, src/api/usage.ts, and src/x402/metering.ts to trace how a presented key is authenticated and how enforcement calculates usage. Then inspect the existing Vitest tests and run npm test. Done means callers can see only their own enforcement-matched usage, the response is no-store, and a test verifies one key cannot read another's usage.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

area:api-quality difficulty:intermediate help wanted points:150
Background

src/api/usage.ts serves /admin/usage/:keyId and /admin/usage, both behind
ADMIN_TOKEN. Usage is metered per key, quotas are enforced per key, and the
only person who cannot see any of it is the person whose key it is.

So a caller discovers their quota by hitting it. For a paid API where exceeding
a quota can mean a 402 or a blocked request, that is the one number they need
in advance.

What to build
  • A route a caller reads with their own key, returning their own usage:
    requests used against each window, quota remaining, and when it resets.
  • It must be impossible to read another key's usage through it. The key
    presented determines the answer — never a parameter.
  • Reflect the same numbers the enforcement uses. Two sources of truth here means
    a caller is told they have room and then refused.
  • no-store on the response: it is per-caller, and a shared cache must never
    hold it.
Acceptance criteria
  • A caller can read their own usage with their own key
  • No parameter can make it return another key's usage
  • The numbers match what enforcement uses
  • The response is no-store
  • A test asserts one key cannot see another's usage

Drips Wave · Complexity: Intermediate · 150 points

Repo: Divinity-Labs/Lens. Auth is src/api/auth.ts, key minting
src/api/admin.ts, usage reporting src/api/usage.ts, metering
src/x402/metering.ts, the ApiKey model in prisma/schema.prisma.

Run the tests: npm test. The tests are vitest, not jest. A single file
is npx vitest run src/__tests__/auth.test.ts.

Load test (prices) is already failing on main. Not your PR.

Do not weaken what is already right. Three things are correct today and
should survive every change here:

  • generateApiKey() is lens_ plus randomBytes(24) — 192 bits. Do not
    shorten it, and do not make it guessable or sequential.
  • hashApiKey() is an unsalted SHA-256. That is correct for a
    high-entropy random key: it must stay fast and deterministic so a lookup is
    one indexed query. Do not "improve" it into bcrypt or argon2 — those are for
    low-entropy human passwords, and here they would only make every request slow.
  • Only the hash is ever stored. The plaintext is returned once, at creation,
    and never again.

Admin routes carry config: { public: true }. That does not mean public —
it means "skip the API-key hook", because they enforce ADMIN_TOKEN instead.
Removing that flag locks the admin surface behind the keys it exists to mint.

Never elide an address, a key or a token in code, comments, tests or
documentation. Write it in full or not at all — and never write a real key
anywhere.

Required: Before submitting, join the contributor Telegram so your work can be tracked and counted toward the Stellar Wave: https://t.me/+fxHXq8f1SwlkZDBk

Lenguaje dominante
TypeScript
Estrellas
4
Forks
71
Merge medio
3 d 15 h
PR fusionados (30 d)
157

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Divinity-Labs/Lens

Todos los issues de Divinity-Labs/Lens

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.