Add Password Strength Validation During User Registration#521
Add Password Strength Validation During User Registration#521nikita-kashyap-codes wants to merge 1 commit into
Conversation
📝 WalkthroughWalkthroughThe ChangesPassword Strength Validation and Response Update
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related issues
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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.
Inline comments:
In `@backend/src/controllers/auth.controller.js`:
- Around line 45-50: Normalize the incoming email before performing the
duplicate lookup so it matches how users are created: compute a normalizedEmail
(e.g., email.toLowerCase().trim()) and use User.findOne({ email: normalizedEmail
}) for the duplicate check, then reuse normalizedEmail when creating the user so
User.findOne, the duplicate check, and the creation all use the same normalized
value.
- Around line 62-67: The signup response omits the statusMood field causing an
inconsistent API shape versus login and googleAuth; update the signup response
in the signup handler to include statusMood: user.statusMood || null (same key
and fallback used by login and googleAuth) so the returned payloads from signup,
login, and googleAuth are consistent; locate the signup function in
auth.controller.js and add the statusMood property to the res.status(201).json
object alongside _id, name, email, and profilePicture.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: f4d2b086-b8cb-4799-9f03-1d34e4f45d96
📒 Files selected for processing (1)
backend/src/controllers/auth.controller.js
| const existing = await User.findOne({ email }); | ||
| if (existing) { | ||
| return res.status(409).json({ | ||
| message: "An account with this email already exists", | ||
| }); | ||
| } |
There was a problem hiding this comment.
Critical: Email duplicate check must normalize the email consistently with user creation.
The duplicate check queries using the raw email parameter, but line 56 creates the user with email.toLowerCase().trim(). This normalization mismatch allows the duplicate check to pass for emails that differ only in casing (e.g., "Test@Example.com" vs "test@example.com"), which will either:
- Create duplicate accounts if the database lacks a case-insensitive unique constraint, or
- Cause a database constraint violation error after the duplicate check passed
🔧 Proposed fix
- const existing = await User.findOne({ email });
+ const existing = await User.findOne({ email: email.toLowerCase().trim() });
if (existing) {
return res.status(409).json({📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const existing = await User.findOne({ email }); | |
| if (existing) { | |
| return res.status(409).json({ | |
| message: "An account with this email already exists", | |
| }); | |
| } | |
| const existing = await User.findOne({ email: email.toLowerCase().trim() }); | |
| if (existing) { | |
| return res.status(409).json({ | |
| message: "An account with this email already exists", | |
| }); | |
| } |
🤖 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 `@backend/src/controllers/auth.controller.js` around lines 45 - 50, Normalize
the incoming email before performing the duplicate lookup so it matches how
users are created: compute a normalizedEmail (e.g., email.toLowerCase().trim())
and use User.findOne({ email: normalizedEmail }) for the duplicate check, then
reuse normalizedEmail when creating the user so User.findOne, the duplicate
check, and the creation all use the same normalized value.
| res.status(201).json({ | ||
| _id: user._id, | ||
| name: user.name, | ||
| email: user.email, | ||
| profilePicture: user.profilePicture, | ||
| }); |
There was a problem hiding this comment.
API contract inconsistency: Response payload omits statusMood field.
The signup response returns only _id, name, email, and profilePicture, but the login (line 96) and googleAuth (line 149) endpoints include statusMood: user.statusMood || null. This creates an inconsistent API shape across authentication endpoints.
Impact:
The frontend stores the entire response as authUser (see context snippet 1). The Settings page initializes state from authUser?.statusMood (see context snippet 2). After signup, statusMood will be undefined, but after login/OAuth it will be present. This asymmetry can cause UI inconsistencies or require special handling in downstream components.
🔧 Proposed fix for consistency
res.status(201).json({
_id: user._id,
name: user.name,
email: user.email,
profilePicture: user.profilePicture,
+ statusMood: user.statusMood || null,
});📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| res.status(201).json({ | |
| _id: user._id, | |
| name: user.name, | |
| email: user.email, | |
| profilePicture: user.profilePicture, | |
| }); | |
| res.status(201).json({ | |
| _id: user._id, | |
| name: user.name, | |
| email: user.email, | |
| profilePicture: user.profilePicture, | |
| statusMood: user.statusMood || null, | |
| }); |
🤖 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 `@backend/src/controllers/auth.controller.js` around lines 62 - 67, The signup
response omits the statusMood field causing an inconsistent API shape versus
login and googleAuth; update the signup response in the signup handler to
include statusMood: user.statusMood || null (same key and fallback used by login
and googleAuth) so the returned payloads from signup, login, and googleAuth are
consistent; locate the signup function in auth.controller.js and add the
statusMood property to the res.status(201).json object alongside _id, name,
email, and profilePicture.
|
hi,@UTKARSHH20 please review my pr |
1 participant
This PR enhances user account security by adding password strength validation during user registration. Users must now create passwords that meet minimum security requirements before an account can be created.
Type of Change
Related Issue
Closes #516
Manual Testing
PR Checklist
Additional Notes
Implemented password validation with the following requirements:
Invalid passwords now return a clear validation error message during signup.
Summary by CodeRabbit