fix(security): scope comment resolve and delete by session — Closes #204 - #209
Conversation
|
Warning Review limit reached
Next review available in: 55 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: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
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 |
07d48f6
into
harsharajkumar-273:main
Closes #204
Two corrections to the issue
Worth stating up front, since neither name in the issue exists in the code:
resolveComment, notupdateCommentauthor, notauthorLoginThe substance holds — both methods key on
commentIdalone with no scoping filter — but the specifics were wrong and I would rather correct them than let them sit.The change
deleteCommenttakes the same treatment.sessionIdis required rather than optional. An optional scoping parameter is one a caller can forget, which reproduces the original defect with extra steps.Why session and not author
The issue left this open as a product call, and it still is — but the two answers are not equally safe to guess at.
Any route reaching these methods is already behind
checkWorkspaceOwner, so the session is the boundary that has actually been authorised. Scoping to it adds a check that cannot be wrong.Adding an
authorfilter would silently answer a different question: whether a workspace owner may resolve or delete someone else's comment. That is a moderation decision, and encoding it here by accident is exactly the kind of choice that gets discovered later rather than made deliberately.So this closes the hole that is unambiguous and leaves the one that needs a decision visible — the doc comment says so, rather than leaving the next reader to work out why only half the filter is there.
Filtering in the where clause
Rather than fetching and comparing. A post-fetch check leaks whether the comment exists, and the record is briefly in memory either way. Prisma throws
P2025when nothing matches, which maps cleanly to a 404 covering both "no such comment" and "not in this session".Verified
npx prisma generatethennpx tsc --noEmitpasses clean, confirming Prisma 7.8 accepts the compoundwhere: { id, sessionId }on bothupdateanddeletegrepforresolveComment(anddeleteComment(outside the definitions returns nothing — so the added parameter breaks nothingbackend/dev.dbuntouchedRelated
#207 was the same issue filed twice and is closed as a duplicate of this one.