fix: make doubt upvotes forge-proof via secure RPC (#1928) - #1934
fix: make doubt upvotes forge-proof via secure RPC (#1928)#1934atul-upadhyay-7 wants to merge 1 commit into
Conversation
Any authenticated user could set upvotes on any doubt to an arbitrary value (loose UPDATE policy) and insert doubts with fabricated counts (WITH CHECK true). Restore the strict INSERT policy (upvotes = 0 + attribution rules), revoke direct UPDATE from clients, add a one-vote-per-user doubt_upvotes table, and move upvoting to the SECURITY DEFINER upvote_doubt() RPC. Update the frontend to call the RPC instead of computing counts client-side.
|
@atul-upadhyay-7 is attempting to deploy a commit to the durdana3105's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
Warning Review limit reached
Next review available in: 50 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
solve the failing ci test |
Fixes #1928
Problem
doubtsINSERT policy isWITH CHECK (true), so any authenticated user can insert a doubt with a fabricatedupvotescount and arbitrary attribution.upvoteson any doubt to any value (USING (auth.uid() IS NOT NULL)), so ranking can be manipulated directly:Changes
New migration
20260805000005_secure_doubt_upvotes.sql:upvotes = 0;anonymous = true⇒user_id IS NULL,anonymous = false⇒user_id = auth.uid()).REVOKE UPDATE ON public.doubts FROM anon, authenticated.doubt_upvotestable (unique per user + doubt) so each user can vote at most once.upvote_doubt(p_doubt_id)RPC: records the vote (idempotent on duplicates) and atomically incrementsupvotes. GRANTed only toauthenticated.Frontend (
src/pages/AnonymousDoubts.tsx): the upvote handler now callssupabase.rpc("upvote_doubt", ...)instead of computing and writing the count client-side.Verification
npx eslint src/pages/AnonymousDoubts.tsx— clean.npm run typecheck— no new errors.addDoubtinsert (noupvotesfield, correctuser_id/anonymouspairing) satisfies the restored strict policy.