Skip to content

fix(auth): normalize email storage and lookup handling#327

Open
VarshithReddy2006 wants to merge 1 commit into
geturbackend:mainfrom
VarshithReddy2006:fix/email-normalization-auth-321
Open

fix(auth): normalize email storage and lookup handling#327
VarshithReddy2006 wants to merge 1 commit into
geturbackend:mainfrom
VarshithReddy2006:fix/email-normalization-auth-321

Conversation

@VarshithReddy2006

@VarshithReddy2006 VarshithReddy2006 commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

Fixes #321

Summary

This PR normalises email addresses before both storage and lookup across authentication flows.

Changes

  • Normalise email before storing users created via signup.
  • Normalise email before storing users created through social authentication.
  • Normalise social-auth email lookups before account linking.
  • Normalise admin-created user email handling for duplicate checks and storage.

Problem

Authentication flows performed normalised email lookups, while some user creation paths stored raw email values. This could lead to inconsistencies for mixed-case email addresses and make authentication behaviour dependent on how the email was originally stored.

Result

Email storage and lookup now use the same canonical representation (toLowerCase().trim()) across the affected authentication flows, ensuring consistent behaviour and reliable email matching.

Summary by CodeRabbit

  • Bug Fixes
    • Standardized email address formatting across authentication flows to ensure consistent normalization (lowercase, trimmed) during user creation, linking, and sign-up.

@coderabbitai

coderabbitai Bot commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

📝 Walkthrough

Walkthrough

Email normalization (lowercase + trim) is applied consistently at write time across all three user creation flows in userAuth.controller.js: social auth payload building and lookup, email/password signup payload building, and admin user creation (duplicate check, payload build, and response).

Changes

Email Normalization at Write Paths

Layer / File(s) Summary
Social auth payload and lookup normalization
apps/public-api/src/controllers/userAuth.controller.js
buildSocialAuthUserPayload now stores String(profile.email).toLowerCase().trim() in the user payload. findOrCreateSocialUser derives normalizedEmail from profile.email and uses it for the Model.findOne lookup.
Signup payload normalization
apps/public-api/src/controllers/userAuth.controller.js
buildAuthUserPayload call in the signup flow now passes email: normalizedEmail instead of the original destructured email variable.
Admin createAdminUser normalization
apps/public-api/src/controllers/userAuth.controller.js
Computes normalizedEmail = email.toLowerCase().trim() before the existing-user duplicate check, the buildAuthUserPayload call, and the success response's email field.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐇 Hoppity-hop through the login gate,
No more mixed-case causing debate!
Trim and lowercase, neat and right,
Every email stored just tight.
The rabbit's auth flows shine bright! ✨

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The PR title accurately describes the main change: normalizing email storage and lookup handling across authentication flows.
Linked Issues check ✅ Passed All objectives from issue #321 are met: email normalization is applied consistently across signup, social auth, and admin user creation flows; the canonical form (toLowerCase().trim()) is used for both writes and reads.
Out of Scope Changes check ✅ Passed All changes are scoped to email normalization in the userAuth controller; no unrelated modifications are present.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 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 `@apps/public-api/src/controllers/userAuth.controller.js`:
- Around line 1343-1346: The response format in the user creation endpoint does
not conform to the required API response envelope. The current response returns
an object with message and user properties, but it must return an object with
success (boolean), data (containing the user information), and message
properties. Restructure the res.status(201).json() call to wrap the user object
in a data property and add a success property set to true, while keeping the
message property.
🪄 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: 4cc090bc-cf98-4b09-9796-64c76f2f6d36

📥 Commits

Reviewing files that changed from the base of the PR and between fafceb5 and 23dddf2.

📒 Files selected for processing (1)
  • apps/public-api/src/controllers/userAuth.controller.js

Comment on lines 1343 to 1346
res.status(201).json({
message: "User created successfully",
user: { _id: result._id, email, username, createdAt: newUserPayload.createdAt }
user: { _id: result._id, email: normalizedEmail, username, createdAt: newUserPayload.createdAt }
});

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Return the required controller response envelope

This endpoint still returns { message, user } instead of the required { success, data, message } contract.

As per coding guidelines, “All API endpoints must return response format: { success: bool, data: {}, message: "" }.”

Proposed fix
-        res.status(201).json({
-            message: "User created successfully",
-            user: { _id: result._id, email: normalizedEmail, username, createdAt: newUserPayload.createdAt }
-        });
+        res.status(201).json({
+            success: true,
+            data: {
+                user: { _id: result._id, email: normalizedEmail, username, createdAt: newUserPayload.createdAt }
+            },
+            message: "User created successfully"
+        });
🤖 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/public-api/src/controllers/userAuth.controller.js` around lines 1343 -
1346, The response format in the user creation endpoint does not conform to the
required API response envelope. The current response returns an object with
message and user properties, but it must return an object with success
(boolean), data (containing the user information), and message properties.
Restructure the res.status(201).json() call to wrap the user object in a data
property and add a success property set to true, while keeping the message
property.

Source: Coding guidelines

@Nitin-kumar-yadav1307

Copy link
Copy Markdown
Collaborator

@VarshithReddy2006 fix the issue reported by coderabbit

@VarshithReddy2006

Copy link
Copy Markdown
Contributor Author

Hi @Nitin-kumar-yadav1307 ,

I reviewed the CodeRabbit comment.

This PR is scoped specifically to Issue #321 (email normalization). The createAdminUser() response contract already existed before this change, and the email-normalization fix does not modify the endpoint response shape.

I intentionally kept the PR limited to normalizing email storage and lookup behavior to avoid introducing unrelated API-contract changes in the same bug fix.

If you'd prefer the response envelope to be standardized for createAdminUser(), I'm happy to address that in a separate PR focused on response-contract consistency.

Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG]: Authentication workflow stores raw email values but performs normalized email lookups

2 participants