Repository navigation
The key is accepted only as a bearer token, and nothing says so #512
Description
Background
extractBearer reads Authorization: Bearer <key> and nothing else. That is a
reasonable choice, but it is only discoverable by reading src/api/auth.ts:
the README does not describe authentication, and a caller who sends
X-API-Key, a common convention and the one Linq's own API uses, gets a
401 saying the key is missing — which is confusing when they can see they sent
it.
What to build
- Document authentication properly: the header, the format, how to get a key,
what the quotas mean, and what each 401 code means (L247). - A worked example that runs as written.
- Make the "missing key" message name the header it expected.
- Decide whether to also accept
X-API-Key. Accepting both is friendlier;
accepting one is simpler. Either way, write the decision down rather than
leaving it implicit in a helper function.
Acceptance criteria
- Authentication is documented where a new caller will find it
- The example works exactly as written
- The missing-key error names the expected header
- The decision on alternative headers is explicit
- No real key appears in any example
Drips Wave · Complexity: Easy · 100 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()islens_plusrandomBytes(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
Activity
krsnak commentedon Oct 18, 2026
@krsnak has applied to work on this issue as part of the Stellar Wave Program's 10th wave.
ℹ️ Repo Maintainers: To accept this application, review their application or assign @krsnak to this issue.
Miracle656 commentedon Oct 18, 2026
⏸️ Not funded in the current Wave — please do not start yet
This issue is real and the work is wanted, but it is not currently part of the Drips Wave programme, so a PR against it right now would earn no points. I would rather say that plainly up front than have anyone find out after writing the code.
The repo's Wave budget for this round is exhausted — 25,000 points across 271 labelled issues — and this batch was published just after it ran out. That is my error in pacing, not a reflection on the issue.
What happens next: it will be added to the Wave when the next round opens, at the points value in its label. The description, the acceptance criteria and the code references all stay as they are, so nothing here is wasted.
If you want something to work on today, pick an issue that is already in the Wave — the
Stellar Wavelabel plus an unassigned state is the signal, and Drips will let you apply for it. If Drips will not let you apply for an issue, that is the budget, not you.If you have already started on this one, say so here and I will make sure you are first in line for it when the next round opens.
drips-wave commentedon Oct 18, 2026
Congratulations, @krsnak! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on October 22, 2026.
🧑💻 @krsnak: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.
Warning
When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.
🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.
🌊 Happy Wave 🌊
krsnak commentedon Oct 21, 2026
Hi @Miracle656,
For the record, I am assigned to #512 in Drips with an October 22 deadline, but your comment explicitly asks contributors not to start because the issue is not funded in the current Wave: #512 (comment)
I am respecting that instruction and have not started implementation or submitted a PR. I previously asked for clarification about both #510 and #512 on #510, but the assignment is still active.
Could you and/or the Drips team please confirm that holding off will not negatively affect my contributor standing or completion record? If the issue is not eligible for this Wave, please release or defer the assignment without penalty or consumption of my application slots. I can proceed once its eligibility is confirmed. Thank you.