Normalize auth email handling to prevent false login failures

[Copilot]

Users could fail login with valid credentials when the entered email had different casing or surrounding whitespace than the stored value. The auth flow treated these as different strings during lookup.

• Problem summary

  • Login and duplicate-email checks were case/whitespace sensitive at query time, causing avoidable auth failures and inconsistent registration behavior.

• Backend auth behavior changes

  • Added centralized email normalization (Trim().ToLowerInvariant()) in AuthService.
  • Applied normalization before:
    • Register uniqueness check
    • Register persistence
    • Login user lookup
  • Preserves existing API contract and response shape; only lookup semantics changed.

• Regression coverage

  • Added focused AuthService tests for:
    • normalized email persistence on register
    • login success with case/whitespace email variants
    • duplicate registration rejection across case variants

private static string NormalizeEmail(string email)
{
    return email.Trim().ToLowerInvariant();
}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
taskflow-dotnet	Ready	Preview, Comment	Apr 25, 2026 7:05pm

[Copilot]

Pull request overview

This PR aims to prevent authentication and registration failures caused by email casing and surrounding whitespace differences by normalizing emails during auth operations.

Changes:

• Added centralized email normalization (Trim().ToLowerInvariant()) in AuthService.
• Applied normalization to registration uniqueness checks, persisted user emails, and login lookups.
• Added AuthService unit tests covering normalized persistence, login with case/whitespace variants, and duplicate detection across case variants.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
Backend/Services/Implementations/AuthService.cs	Normalizes emails in Register and Login, and adds a NormalizeEmail helper.
Backend.Tests/Services/AuthServiceTests.cs	Adds tests validating normalized persistence, case/whitespace-tolerant login, and duplicate rejection.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The added tests cover normalization when registration happens through AuthService, but they don’t cover backward compatibility for pre-existing users whose emails were stored with mixed casing/whitespace (or were updated elsewhere and not normalized). Adding a test that seeds a User directly into the context with a non-normalized Email and then verifies Login succeeds would prevent regressions where existing accounts get locked out after this change.

Suggested change

	[Fact]
	[Fact]
	public async Task Login_AllowsNormalizedEmailForExistingUserWithNonNormalizedStoredEmail()
	{
	await using var context = CreateContext();
	var service = CreateService(context);
	var registrationResult = await service.Register(new RegisterDto
	{
	Name = "Test User",
	Email = "test.user@example.com",
	Password = "Password123!"
	});
	Assert.True(registrationResult.Success);
	var existingUser = await context.Users.SingleAsync();
	existingUser.Email = " TEST.User@Example.COM ";
	await context.SaveChangesAsync();
	var result = await service.Login(new LoginDto
	{
	Email = "test.user@example.com",
	Password = "Password123!"
	});
	Assert.True(result.Success);
	Assert.False(string.IsNullOrWhiteSpace(result.Token));
	Assert.NotNull(result.User);
	Assert.Equal(" TEST.User@Example.COM ", result.User!.Email);
	}
	[Fact]

[Copilot]

Register still enforces email uniqueness only at the application level (query then insert). Without a database-level unique constraint/index on the canonical email value, concurrent registrations can still create duplicate accounts for the same email (race condition), and the new normalization makes this check more central. Consider adding a DB unique index/constraint on a normalized/canonical email (e.g., CITEXT column or a unique index on lower(trim(email))) to make this robust.

[Copilot]

Register now normalizes the input email and then does a strict equality lookup (x.Email == normalizedEmail). This will miss any existing users whose Email was previously stored with different casing/whitespace (including users created before this change or updated via other flows like ProfileService), which can allow duplicate registrations for the same logical email and can fragment accounts. Consider either (a) migrating/normalizing existing stored emails (and enforcing it everywhere emails are written) or (b) performing the lookup using a normalized comparison on the stored value as well (e.g., trimming/lowercasing in the query) until data is fully normalized, ideally backed by a DB unique constraint on the normalized value.

Suggested change

	.FirstOrDefaultAsync(x => x.Email == normalizedEmail && !x.IsDeleted);
	.FirstOrDefaultAsync(x => x.Email != null && x.Email.Trim().ToLower() == normalizedEmail && !x.IsDeleted);

[Copilot]

Login uses normalizedEmail but still compares with strict equality against the stored Email (x.Email == normalizedEmail). If existing rows contain mixed-case or whitespace (or if other parts of the app persist non-normalized emails), those users will no longer be able to log in even if they enter the same email they previously used. To avoid locking out existing accounts, either normalize/migrate stored emails, or normalize the stored value in the query (e.g., trim/lowercase) as a compatibility bridge.

Suggested change

	.FirstOrDefaultAsync(x => x.Email == normalizedEmail && !x.IsDeleted);
	.FirstOrDefaultAsync(x => !x.IsDeleted && x.Email != null && x.Email.Trim().ToLower() == normalizedEmail);

[Copilot]

AuthService introduces its own NormalizeEmail helper, but other services (e.g., ProjectService) already have similar logic and ProfileService currently trims but does not lowercase on persistence. This inconsistency means user emails can end up stored in multiple formats, reintroducing auth/duplicate-check issues. Consider centralizing normalization in a shared utility and using it consistently anywhere User.Email is written (including profile updates), plus aligning uniqueness checks accordingly.