fix: enforce Accounts_AllowPasswordChange in forgot password flow#40969
fix: enforce Accounts_AllowPasswordChange in forgot password flow#40969ErnandesCosta wants to merge 1 commit into
Conversation
Fixes RocketChat#9434 The sendForgotPasswordEmail function was not checking the Accounts_AllowPasswordChange setting before sending a reset email, allowing users to bypass the admin-configured restriction via the forgot password flow. Add early return when Accounts_AllowPasswordChange is false and add unit tests covering all affected branches.
|
Looks like this PR is not ready to merge, because of the following issues:
Please fix the issues and try again If you have any trouble, please check the PR guidelines |
🦋 Changeset detectedLatest commit: 40a252e The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
WalkthroughAdds a four-line early guard in ChangesEnforce Accounts_AllowPasswordChange in forgot password flow
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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 |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/meteor/server/methods/sendForgotPasswordEmail.ts (1)
20-28:⚠️ Potential issue | 🟠 Major | ⚡ Quick winMove the global password-change guard before user lookup to avoid an account-enumeration side channel.
At Line 22 the function returns
truefor unknown emails before checkingAccounts_AllowPasswordChangeat Line 26. When the setting isfalse, existing users returnfalsewhile unknown users returntrue(observable through the Meteor method at Line 45), which leaks existence and does an unnecessary DB read.Suggested fix
export const sendForgotPasswordEmail = async (to: string): Promise<boolean | undefined> => { const email = to.trim().toLowerCase(); + if (!settings.get('Accounts_AllowPasswordChange')) { + return false; + } + const user = await Users.findOneByEmailAddress(email, { projection: { _id: 1, services: 1 } }); if (!user) { return true; } - - if (!settings.get('Accounts_AllowPasswordChange')) { - return false; - }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/meteor/server/methods/sendForgotPasswordEmail.ts` around lines 20 - 28, Move the Accounts_AllowPasswordChange setting check before the user lookup in the sendForgotPasswordEmail method. Currently, the function checks if the user exists first and returns true for unknown emails, then checks the global password-change setting afterwards. This creates a timing side channel that reveals account existence. Reorder the logic so that the check for settings.get('Accounts_AllowPasswordChange') happens before Users.findOneByEmailAddress is called, ensuring that all requests return the same response (false) when the setting is disabled, regardless of whether the email belongs to an existing user.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@apps/meteor/server/methods/sendForgotPasswordEmail.ts`:
- Around line 20-28: Move the Accounts_AllowPasswordChange setting check before
the user lookup in the sendForgotPasswordEmail method. Currently, the function
checks if the user exists first and returns true for unknown emails, then checks
the global password-change setting afterwards. This creates a timing side
channel that reveals account existence. Reorder the logic so that the check for
settings.get('Accounts_AllowPasswordChange') happens before
Users.findOneByEmailAddress is called, ensuring that all requests return the
same response (false) when the setting is disabled, regardless of whether the
email belongs to an existing user.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: d7204f5f-a118-43ae-a37a-f0ad6e49551a
📒 Files selected for processing (3)
.changeset/fix-password-change-bypass.mdapps/meteor/server/methods/sendForgotPasswordEmail.spec.tsapps/meteor/server/methods/sendForgotPasswordEmail.ts
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: cubic · AI code reviewer
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (.cursor/rules/playwright.mdc)
**/*.{ts,tsx,js}: Write concise, technical TypeScript/JavaScript with accurate typing in Playwright tests
Avoid code comments in the implementation
Files:
apps/meteor/server/methods/sendForgotPasswordEmail.spec.tsapps/meteor/server/methods/sendForgotPasswordEmail.ts
**/*.spec.ts
📄 CodeRabbit inference engine (.cursor/rules/playwright.mdc)
**/*.spec.ts: Use descriptive test names that clearly communicate expected behavior in Playwright tests
Use.spec.tsextension for test files (e.g.,login.spec.ts)
Files:
apps/meteor/server/methods/sendForgotPasswordEmail.spec.ts
🧠 Learnings (7)
📚 Learning: 2026-02-24T19:22:48.358Z
Learnt from: juliajforesti
Repo: RocketChat/Rocket.Chat PR: 38493
File: apps/meteor/tests/e2e/omnichannel/omnichannel-send-pdf-transcript.spec.ts:66-67
Timestamp: 2026-02-24T19:22:48.358Z
Learning: In Playwright end-to-end tests (e.g., under apps/meteor/tests/e2e/...), prefer locating elements by translated text (getByText) and ARIA roles (getByRole) over data-qa attributes. If translation values change, update the corresponding test locators accordingly. Never use data-qa locators. This guideline applies to all Playwright e2e test specs in the repository and helps keep tests robust to UI text changes and accessible semantics.
Applied to files:
apps/meteor/server/methods/sendForgotPasswordEmail.spec.ts
📚 Learning: 2026-02-26T19:25:44.063Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In the Rocket.Chat repository, do not reference Biome lint rules in code review feedback. Biome is not used even if biome.json exists; only reference Biome rules if there is explicit, project-wide usage documented. For TypeScript files, review lint implications without Biome guidance unless the project enables Biome rules.
Applied to files:
apps/meteor/server/methods/sendForgotPasswordEmail.spec.tsapps/meteor/server/methods/sendForgotPasswordEmail.ts
📚 Learning: 2026-02-26T19:25:44.063Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In this repository (RocketChat/Rocket.Chat), Biome lint rules are not used even if a biome.json exists. When reviewing TypeScript files (e.g., packages/ui-voip/src/providers/useMediaSession.ts), ensure lint suggestions do not reference Biome-specific rules. Rely on general ESLint/TypeScript lint rules and project conventions instead.
Applied to files:
apps/meteor/server/methods/sendForgotPasswordEmail.spec.tsapps/meteor/server/methods/sendForgotPasswordEmail.ts
📚 Learning: 2026-03-06T18:10:15.268Z
Learnt from: tassoevan
Repo: RocketChat/Rocket.Chat PR: 39397
File: packages/gazzodown/src/code/CodeBlock.spec.tsx:47-68
Timestamp: 2026-03-06T18:10:15.268Z
Learning: In tests (especially those using testing-library/dom/jsdom) for Rocket.Chat components, the HTML <code> element has an implicit ARIA role of 'code'. Therefore, screen.getByRole('code') or screen.findByRole('code') will locate <code> elements even without a role attribute. Do not flag findByRole('code') as invalid in reviews; prefer using the implicit role instead of adding role="code" unless necessary for accessibility.
Applied to files:
apps/meteor/server/methods/sendForgotPasswordEmail.spec.ts
📚 Learning: 2026-03-09T18:39:14.020Z
Learnt from: Harxhit
Repo: RocketChat/Rocket.Chat PR: 39476
File: apps/meteor/server/methods/addAllUserToRoom.ts:0-0
Timestamp: 2026-03-09T18:39:14.020Z
Learning: When implementing batch processing in server methods, favor a single data pass to collect both the items and any derived fields needed for validation. Use the same dataset for both validation and processing to avoid races between validation and execution, and document the approach in code comments. Apply this pattern to similar Meteor Rocket.Chat server methods under apps/meteor/server/methods to prevent race conditions and ensure consistent batch behavior.
Applied to files:
apps/meteor/server/methods/sendForgotPasswordEmail.spec.tsapps/meteor/server/methods/sendForgotPasswordEmail.ts
📚 Learning: 2026-05-06T12:21:44.083Z
Learnt from: juliajforesti
Repo: RocketChat/Rocket.Chat PR: 40256
File: apps/meteor/client/components/CreateDiscussion/CreateDiscussion.tsx:121-149
Timestamp: 2026-05-06T12:21:44.083Z
Learning: Field wrappers in rocket.chat/fuselage-forms (Field, FieldLabel, FieldRow, FieldError, FieldHint) auto-create htmlFor/id associations, aria-describedby, and role="alert" for errors. Do not manually set htmlFor, id, aria-describedby, or role attributes when using these wrappers. This automatic wiring does not apply to plain rocket.chat/fuselage components, which require explicit ID wiring per the accessibility docs. In code reviews, prefer using fuselage-forms wrappers for form fields and verify there is no unnecessary manual ID/aria wiring in files that use these wrappers. If a component uses plain fuselage components, ensure proper id wiring as per docs.
Applied to files:
apps/meteor/server/methods/sendForgotPasswordEmail.spec.tsapps/meteor/server/methods/sendForgotPasswordEmail.ts
📚 Learning: 2026-03-16T21:50:37.589Z
Learnt from: amitb0ra
Repo: RocketChat/Rocket.Chat PR: 39676
File: .changeset/migrate-users-register-openapi.md:3-3
Timestamp: 2026-03-16T21:50:37.589Z
Learning: For changes related to OpenAPI migrations in Rocket.Chat/OpenAPI, when removing endpoint types and validators from rocket.chat/rest-typings (e.g., UserRegisterParamsPOST, /v1/users.register) document this as a minor changeset (not breaking) per RocketChat/Rocket.Chat-Open-API#150 Rule 7. Note that the endpoint type is re-exposed via a module augmentation .d.ts in the consuming package (e.g., packages/web-ui-registration/src/users-register.d.ts). In reviews, ensure the changeset clearly states: this is a non-breaking change, the major version should not be bumped, and the changeset reflects a minor version bump. Do not treat this as a breaking change during OpenAPI migrations.
Applied to files:
.changeset/fix-password-change-bypass.md
🔇 Additional comments (2)
.changeset/fix-password-change-bypass.md (1)
1-6: LGTM!apps/meteor/server/methods/sendForgotPasswordEmail.spec.ts (1)
1-58: LGTM!
Description
Fixes #9434
When an admin sets Administration → Accounts → Allow Password Change to
false, users were still able to receive a password reset email via the "Forgot Password" flow and effectively change their password, bypassing the restriction.Root Cause
sendForgotPasswordEmail.tsonly guarded against OAuth users (Accounts_AllowPasswordChangeForOAuthUsers) but never checkedAccounts_AllowPasswordChangefor regular password-based users.Fix
Added an early return in
sendForgotPasswordEmailwhenAccounts_AllowPasswordChangeisfalse, preventing the reset email from being dispatched regardless of the user's authentication method.Tests
Added unit tests for
sendForgotPasswordEmailcovering:true(no email leak)Accounts_AllowPasswordChange = false→ returnsfalse, no email sentAccounts_AllowPasswordChangeForOAuthUsers = false→ returnsfalse, no email senttrueChecklist
developbranchpatch)Summary by CodeRabbit