fix: add auth checks to transaction server actions#1860
fix: add auth checks to transaction server actions#1860
Conversation
getAccumulativePaymentsData and getAccumulativeTransactionsData were missing authentication and authorization checks, allowing any caller to query internal payment data for arbitrary app IDs via direct server action invocation. Added getSession() + team membership verification matching the pattern used by the sibling getTransactionData function. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 533ce774da
ℹ️ 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".
| const isTeamMember = user?.hasura?.memberships?.some( | ||
| (membership) => membership.team?.id === teamId, | ||
| ); |
There was a problem hiding this comment.
Verify app ownership before authorizing access
This authorization only validates membership for the route-derived teamId, but the data fetch is keyed only by appId. That means a user who is a member of Team A can invoke this server action from a Team A route while supplying an appId that belongs to Team B, and isTeamMember still passes before returning Team B’s payment/transaction data. Please enforce that the requested appId belongs to the authorized team (or query by both team and app) before calling the internal endpoint; the same issue is duplicated in getAccumulativeTransactionsData.
Useful? React with 👍 / 👎.
…heck The previous auth check only verified team membership from the URL path, allowing a user on Team A to supply an appId belonging to Team B. Replaced with getIsUserAllowedToReadApp which queries the database to confirm the authenticated user is a member of the app's owning team. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
PR Type
Description
Adds authentication and team membership authorization checks to
getAccumulativePaymentsDataandgetAccumulativeTransactionsDataserver actions. These functions were directly invocable via HTTP POST (Next-Action header) with an arbitraryappId, bypassing the layout-level team membership guard and exposing transaction records (wallet addresses, amounts, tx hashes) for any mini-app. The fix follows the same auth pattern used by the siblinggetTransactionDatafunction in the same directory.Checklist