Repository navigation
fix: require ManageMessages permission to reset another user's context - #49
Conversation
Summary by BeetleThis PR implements a critical security fix for the 📁 File Changes Summary (Consolidated across all commits):
Total Changes: 1 file changed, +17 additions, -4 deletions 🎯 Key Changes:
📊 Impact Assessment:
⚙️ SettingsSeverity Threshold: 📖 User Guide
|
![beetle-ai[bot]](https://avatars.githubusercontent.com/in/1636950?s=60&v=4){kind=small}
| const hasPerms = message.member?.permissions.has( | ||
| PermissionFlagsBits.ManageMessages, | ||
| ); |
There was a problem hiding this comment.
The permission check uses optional chaining but doesn't explicitly handle the null case. If message.member is null, the expression evaluates to undefined, which makes !hasPerms truthy on line 19, incorrectly denying permission. This could cause false negatives in edge cases.
Confidence: 4/5
Suggested Fix
| const hasPerms = message.member?.permissions.has( | |
| PermissionFlagsBits.ManageMessages, | |
| ); | |
| const hasPerms = message.member?.permissions.has( | |
| PermissionFlagsBits.ManageMessages, | |
| ) ?? false; | |
Use the nullish coalescing operator (??) to explicitly default to false when message.member is null or undefined. This ensures the permission check behaves predictably in all scenarios.
Prompt for AI
Copy this prompt to your AI IDE to fix this issue locally:
In src/commands/ai/resetctx.ts around line 16-18, the permission check uses optional chaining
but doesn't handle the null case explicitly. When message.member is null, hasPerms becomes
undefined instead of false, causing the permission denial logic to trigger incorrectly.
Add the nullish coalescing operator (?? false) to ensure hasPerms defaults to false when
message.member is null or undefined.
📍 This suggestion applies to lines 16-18
|
Note Linting checks passed successfully 🎉 All formatting and code quality checks are clean. You're good to merge 🚀 |
Summary by BeetleThis PR fixes a potential null reference bug in the 📁 File Changes Summary (Consolidated across all commits):
Total Changes: 1 file changed, +3 additions, -3 deletions 🎯 Key Changes:
📊 Impact Assessment:
⚙️ SettingsSeverity Threshold: 📖 User Guide
|
|
✅ You're good to merge this PR! No issues found. Great job! Settings⚙️ SettingsSeverity Threshold: 📖 User Guide
|
|
Note Linting checks passed successfully 🎉 All formatting and code quality checks are clean. You're good to merge 🚀 |
|
@calebephrem :3 |
|
I don't think this's right, someone should be abled to reset only his context (nomatter what permission the user has) |
well cant mods reset someones context |
|
no |
yap yap yap sahur ok :3 |
|
give me 10 to 11 business hours |
Summary by BeetleThis PR implements a security fix that restricts the 📁 File Changes Summary (Consolidated across all commits):
Total Changes: 1 file changed, +7 additions, -24 deletions 🎯 Key Changes:
📊 Impact Assessment:
⚙️ SettingsSeverity Threshold: 📖 User Guide
|
|
Note Linting checks passed successfully 🎉 All formatting and code quality checks are clean. You're good to merge 🚀 |
|
✅ You're good to merge this PR! No issues found. Great job! Settings⚙️ SettingsSeverity Threshold: 📖 User Guide
|
| const mentioned = message.mentions.users.first(); | ||
| if (mentioned && mentioned.id !== message.author.id) { | ||
| await message.reply("You can only reset your own context."); | ||
| return; | ||
| } | ||
|
|
There was a problem hiding this comment.
ion think this part is necessary but informative ig
|
MERGE |
|
lol alr |
|
thx for contributing :3 |
What
Adds a permission check to the command so that only users with Manage Messages permission can reset someone else's conversation context. Anyone can still reset their own context.
Why
Previously any user could reset any other user's context by mentioning them, which is an abuse vector.
Changes
Behavior