Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

A caller cannot see their own usage

クローズ
  • 何か問題がありますか？
#513 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@sparkysolutions10-pixel がすでに取り組んでいます。

2026年10月19日 から。

  • #568 @sparkysolutions10-pixel による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
55/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
typescript
領域
api, authentication

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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

主要言語
TypeScript
スター
4
フォーク
71
平均マージ
2日 8時間
マージ済み PR（30日）
93

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Divinity-Labs/Lens のほかの issue

Divinity-Labs/Lens の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。