fix: align frontend username validation with backend Zod schema#466
fix: align frontend username validation with backend Zod schema#466anshul23102 wants to merge 1 commit into
Conversation
✅ Deploy Preview for github-spy ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Warning Review limit reached
Your plan currently allows 1 review/hour. Refill in 59 minutes and 55 seconds. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more review capacity refills, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than trial, open-source, and free plans. In all cases, review capacity refills continuously over time. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ 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 |
|
Hi @GitMetricsLab team, checking in on this one. The username validation mismatch was causing two real failure modes: usernames like |
Fixes GitMetricsLab#413 The frontend signup form validated usernames against /^[A-Za-z\s]+$/, which only accepted plain letters and spaces. The backend Zod schema in backend/validators/authValidator.js accepts letters, digits, and underscores (/^[a-zA-Z0-9_]+$/) and enforces a minimum length of 3 and a maximum of 30. These two rulesets directly contradicted each other in two ways: 1. Valid usernames containing digits or underscores (e.g. dev_user1, john99) were blocked by the frontend with the misleading error "Only letters are allowed", even though the backend would accept them. 2. Usernames containing spaces (e.g. "john doe") passed the frontend check but were rejected by the backend, producing a confusing server-side error after the network request was already made. Additionally, the frontend had no length checks, so a one-character username would pass client-side validation but be rejected by the backend's min(3) rule. Changes in src/pages/Signup/Signup.tsx: Added named module-level constants (USERNAME_REGEX, USERNAME_MIN, USERNAME_MAX, USERNAME_ERROR) that document the backend rule and serve as a single source to update when the backend changes. The comment references the validator file explicitly to make the coupling visible to future maintainers. Updated the username validation block in handleChange and handleSubmit to: - Check min length (3 characters) with a clear error message - Check max length (30 characters) with a clear error message - Test the corrected regex /^[a-zA-Z0-9_]+$/ against the trimmed value - Use USERNAME_ERROR as the error message to match the backend exactly The handleSubmit block now trims the username once into a local variable before the ternary chain, avoiding repeated .trim() calls. No other validation logic was modified.
7d4806b to
597bead
Compare
Fixes #413
Problem
The frontend signup form in
src/pages/Signup/Signup.tsxvalidated usernames against/^[A-Za-z\s]+$/(letters and spaces only). The backend Zod schema inbackend/validators/authValidator.jsaccepts a completely different character set:This produced two failure modes:
Mode 1 -- valid usernames blocked at the frontend
Usernames like
dev_user1orjohn99are accepted by the backend but were rejected by the frontend with the misleading error "Only letters are allowed". Users with common username patterns could not register at all.Mode 2 -- invalid usernames accepted by the frontend, rejected by the backend
Usernames containing spaces (e.g.
john doe) passed the frontend check but were rejected by the backend after the network request was made, surfacing as a confusing server-side error rather than an inline form error.Mode 3 -- length constraints missing from the frontend
The backend enforces
min(3)andmax(30). The frontend had no length checks, so a 1 or 2-character username would pass client-side validation and produce a backend rejection instead of an immediate inline error.Fix
src/pages/Signup/Signup.tsxAdded named module-level constants that document the backend rule and serve as a single place to update when the backend schema changes:
Updated both validation sites (
handleChangefor inline feedback andhandleSubmitfor pre-submit guard) to:USERNAME_ERRORto match the backend error message exactlyThe
handleSubmitblock now trims the username once into a local variable before the validation chain, removing repeated.trim()calls.Testing
dev_user1john_doejohn doeaba* 31alice