Harden self-service API auth and redemption integrity

[darthnithin]

Summary

• require verified app-user auth for self-service donor and GET Tools routes, and derive identity server-side instead of trusting client userId
• tighten related surfaces by fixing /api/users/me, replacing reflective CORS with an allowlist, and moving revalidation secrets off the URL
• make redemption recording idempotent with a unique redemptions.claim_code_id constraint and include the security audit report in the repo

Testing

• npm run typecheck
• npm run db:generate

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
slugswap	Ready	Preview, Comment	Apr 1, 2026 10:55pm

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7ab15f7801

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Return redemption result only after idempotent write succeeds

In concurrent check-redemption polls, the transaction can hit updatedClaims.length === 0 or insertedRedemptions.length === 0 (because another request already redeemed the claim), but those return statements exit only the transaction callback, not detectRedemption. The function then still returns { amount, accountName }, so the API can report a redemption amount derived from the current balance delta even when this request did not persist that amount, which can disagree with the stored claim/redemption record. This shows up when overlapping polls race on the same claim.

Useful? React with 👍 / 👎.

[darthnithin]

i think this is ok