[#636] Add auth to real-time indexer endpoints

[realproject7]

Summary

• lib/index-auth.ts: Shared verifyIndexAuth() that checks NEXT_PUBLIC_INDEX_TOKEN as Bearer header. Fails closed in production when token is unset.
• 4 indexer routes (trade, storyline, plot, donation): All now verify auth before processing. Unauthenticated calls return 401.
• lib/index-fetch.ts: Client-side indexFetch() wrapper that auto-includes the auth header.
• Frontend callers: TradingWidget, DonateWidget, usePublish all use indexFetch().

Prevents DoS via RPC cost amplification from unauthenticated indexer spam.

Fixes #636
Tracks realproject7/agent-os#316

Deploy note

Set NEXT_PUBLIC_INDEX_TOKEN env var in Vercel before deploying. Without it, indexer endpoints will reject all calls in production.

Test plan

• POST to any indexer endpoint without auth header → 401
• Create storyline via UI → indexing works (frontend passes auth)
• Make a trade → trade indexing works
• Donate → donation indexing works
• Build passes

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
plotlink	Ignored		Mar 30, 2026 8:05pm

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The endpoint checks are wired up, but the chosen auth mechanism does not provide real protection because the shared token is exposed to every browser client.

Findings

• [high] The new "auth" token is sourced from NEXT_PUBLIC_INDEX_TOKEN on both the server and the client, which means the secret is bundled into frontend code and can be replayed by any arbitrary caller.
  • File: lib/index-auth.ts:7
  • Suggestion: Use a server-only secret for verification instead of a NEXT_PUBLIC_... variable, and avoid sending a reusable shared secret from browser code. If these endpoints must remain callable from the browser, this needs a different trust model entirely because a public client cannot keep an API key secret.
• [high] indexFetch() explicitly injects that same public token into browser requests, so the PR does not actually satisfy the goal of preventing arbitrary callers from triggering RPC-heavy indexing work.
  • File: lib/index-fetch.ts:6
  • Suggestion: Remove the client-exposed token path and redesign the auth boundary around something the browser cannot disclose, or move the sensitive indexing trigger behind a server-side path that can use a real secret.

Decision

Requesting changes because the current implementation gives a false sense of endpoint protection: anyone can inspect the public bundle or network traffic, recover the token, and continue calling the indexer routes.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

Renaming the public token to NEXT_PUBLIC_INDEX_KEY and documenting it as a "speed bump" does not resolve the underlying issue: arbitrary callers can still recover the key and hit the indexer routes.

Findings

• [high] The PR now explicitly documents that the key is embedded in the client bundle, which confirms this is not real endpoint authentication and does not meet the ticket goal of preventing arbitrary callers from triggering RPC-heavy work.
  • File: lib/index-auth.ts:4
  • Suggestion: Move the trust boundary server-side, or use a design where the browser does not hold the enforcement credential. If the caller is always a public browser client, a reusable shared key cannot provide meaningful protection.
• [high] The frontend still sends the same public key on every request, so any attacker can inspect the bundle or network traffic and replay it immediately.
  • File: lib/index-fetch.ts:9
  • Suggestion: Remove the client-exposed key path and rework the indexing trigger around a server-controlled credential or another non-public verification mechanism.

Decision

Requesting changes because the revision reframes the limitation but does not actually satisfy the requirement that arbitrary unauthenticated callers be unable to trigger these endpoints.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

Moving the secret out of the client bundle is an improvement, but the new indexFetch() server action is itself a public callable endpoint, so arbitrary callers can still trigger the same RPC-heavy work through that proxy.

Findings

• [high] indexFetch() is a server action imported by public client code, which means site visitors can invoke it and cause the server to attach INDEX_SECRET on their behalf.
  • File: lib/index-fetch.ts:1
  • Suggestion: If the goal is to prevent arbitrary callers, the proxy itself needs caller authorization or another server-side trust check. Simply moving the secret behind a server action does not authenticate who is invoking the action.
• [high] The proxy accepts an arbitrary route string from the caller and then POSTs to that route with the server-only secret, which effectively makes it an authenticated same-origin POST proxy.
  • File: lib/index-fetch.ts:10
  • Suggestion: Do not expose a generic proxy callable from public clients. Narrow this to specific server-owned entrypoints with validated arguments, or move the indexing trigger into a backend path that is not directly invocable by arbitrary browser clients.

Decision

Requesting changes because the current revision changes where the secret lives, but not who is allowed to trigger the work. Public visitors can still use the exposed server action to reach the protected indexer routes.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The server-only secret is an improvement, but the new server-action proxy is still publicly reachable and the added origin check does not provide meaningful caller authentication.

Findings

• [high] The origin validation is bypassable because the Origin header is optional here and client-controlled when present. A non-browser caller can omit it entirely or spoof it, and the action still proceeds to attach INDEX_SECRET.
  • File: lib/index-fetch.ts:33
  • Suggestion: Do not treat Origin as an auth boundary. If this proxy remains callable from public clients, it needs real server-side authorization tied to the caller or another mechanism that a client cannot forge.
• [high] indexFetch() is still a generic public server-action proxy over the four protected routes, so arbitrary site visitors can invoke it and have the server send the secret on their behalf.
  • File: lib/index-fetch.ts:23
  • Suggestion: Narrow this to server-owned flows that are not directly invocable by arbitrary browser clients, or move the indexing trigger to a backend path that is itself authorized.

Decision

Requesting changes because the protected indexer routes are still reachable through a public proxy that does not authenticate who is invoking it, so the ticket goal is still not met.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The tx-hash pivot removes the exposed-secret path, but the shared validator regresses the happy path by dropping the receipt retry logic these routes previously relied on for fresh transactions on load-balanced RPC nodes.

Findings

• [high] validateRecentTx() now does a single publicClient.getTransactionReceipt() and treats any miss as invalid, so legitimate fresh transactions can be rejected spuriously even after the client already waited for confirmation.
  • File: lib/index-auth.ts:21
  • Suggestion: Keep the new recent-tx gate, but build it on top of getReceiptWithRetry() (or equivalent retry/fallback logic) before checking status and block age. All four realtime index routes call this helper now, so the regression affects storyline, plot, donation, and trade indexing.

Decision

Requesting changes because the new auth model is no longer the blocker, but this revision still breaks realtime indexing reliability for legitimate transactions under the existing multi-RPC / load-balanced setup.

[project7-interns]

Verdict: APPROVE

Summary

The latest revision restores the receipt retry path inside validateRecentTx() while keeping the recent-tx gate, so the earlier RPC reliability regression is resolved. The current design now closes the exposed-secret/proxy issues from prior revisions and preserves the load-balanced receipt handling these realtime indexers needed.

Findings

• No blocking findings.

Decision

Approving because the current revision addresses the prior review feedback and is consistent with the issue's recent-tx validation alternative for reducing arbitrary indexer spam.