Sign-in: validate email format (zod) before submitting credentials

Open
  • Is something wrong?
#461 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
66/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
authentication, frontend, testing

Research direction

Start at the sign-in form and trace how it validates fields before calling the auth request; check the sign-up and forgot-password forms for a shared email validation path. Read the design system form’s existing field error pattern and the rule referenced in #413. Add tests showing malformed email produces a field error without an auth call, while valid email still reaches auth and displays credential errors.

Written by the indexing model from the issue text.

Description

bug priority-p2

Sign-in should reject a malformed email before trying credentials

Reported by Stephen (2026-11-07): on the sign-in form he accidentally typed a username instead of an email address. The login failed — as expected — but with the generic invalid-credentials error. A value that is not an email address should never reach the auth call: the form should fail fast with an "invalid email address" validation error.

Expected behavior
  • The email field is validated before the sign-in request is submitted.
  • A malformed value (e.g. a bare username with no @/domain) produces a field-level validation error with a user-friendly message — plain language a non-technical user understands (e.g. "Enter a valid email address"), not a raw library error string and not the credentials error.
  • A well-formed email with wrong credentials keeps the existing invalid-credentials behavior — validation must not mask or replace the real auth errors.
Implementation notes
  • Use zod for the email schema (the repo's validation library), with the error message customized to the user-friendly wording — do not surface zod's default message verbatim.
  • Scope: the sign-in form is the reported case. The same schema should be reused on the other auth forms that take an email (sign-up, forgot password) if they share the field/validation path — one shared schema, not three copies.
  • The sign-in form renders through the design system's page/form surface (business logic stays in the app; the DS form must surface the field error, the same pattern other DS forms use for field-level errors). If the DS form cannot display a field-level validation error, file the gap in spudly/design-system rather than working around it locally (per the #413 rule).
  • Add tests: malformed email → validation error and no auth call is made; well-formed email → auth call proceeds and credential errors still surface as before.
Dominant language
TypeScript
Stars
0
Forks
0
Avg merge
8h 48m
Merged PRs (30d)
209

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from spudly/eciperay

All issues in spudly/eciperay

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.