feat(Users): verify email links

[jakeaturner]

No description provided.

To fix this, we should add rate limiting middleware to the sensitive authorization routes in this router, particularly /verify-email-code (and likely other similar endpoints like /verify-email-token and /resend-verification-email). The standard way in an Express/TypeScript project is to use a well‑known library such as express-rate-limit, configure a limiter with sensible defaults (e.g., small number of attempts per time window for code verification), and plug it into the route’s middleware chain before the expensive controller logic, without changing any existing controller behavior.

Concretely, in server/routes/auth.ts:

1. Add an import for express-rate-limit.
2. Define one or more limiter instances, e.g. emailCodeLimiter, configured for short windows and low max to prevent brute‑force on email verification codes, and possibly a more general authLimiter for other auth endpoints.
3. Apply emailCodeLimiter to the /verify-email-code route by inserting it into the .post() middleware list between validate(...) and catchInternal(...) (or immediately after validate, order between those two doesn’t materially change behavior). For consistency and improved security, we can also apply an appropriate limiter to /verify-email-token and /resend-verification-email, but we will not alter the controllers themselves or their return values.

This requires only adding the express-rate-limit import and definitions at the top of this file, and updating the route definitions where they are already shown.

In general, the fix is to introduce an Express‑compatible rate‑limiting middleware (for example, via express-rate-limit) and apply it to sensitive routes that perform authentication/authorization or other expensive operations. This middleware intercepts requests before they reach the controller, tracks request counts per client (typically keyed by IP), and rejects or delays excessive requests, mitigating denial‑of‑service and brute‑force attacks.

For this file, the least intrusive fix without changing existing functionality is:

• Import a well‑known rate‑limiter (express-rate-limit).
• Define one or more limiter instances with sensible defaults (e.g., separate, stricter limits for auth/verification endpoints).
• Apply the limiter middleware to the affected routes; at minimum the route CodeQL flagged (/verify-email-token), and, following the same rationale, to adjacent registration/verification endpoints (/register, /verify-email-code, /resend-verification-email, /complete-registration, /external-provision), since they are also auth‑related and may be expensive.

Concretely in server/routes/auth.ts:

1. Add an import for express-rate-limit near the top, without modifying existing imports.

2. After router/controller initialization, create a limiter, e.g.:

   • const authRateLimiter = rateLimit({ windowMs: 15 * 60 * 1000, max: 100, standardHeaders: true, legacyHeaders: false });

   These values are examples and can be tuned later; they preserve existing behavior for normal users while limiting abuse.

3. Insert authRateLimiter in the middleware chains of the relevant routes, especially the flagged /verify-email-token handler, ensuring it appears before catchInternal so that rate‑limit responses are generated by the limiter itself and existing controller logic is untouched.

No existing controller logic, validation schemas, or helper functions need changes; we’re only extending middleware chains.

[Copilot]

Pull request overview

This pull request adds token-based email verification links alongside the existing code-based verification system for user registration. Users can now verify their email addresses either by entering a 6-digit code or by clicking a link in their verification email.

Changes:

• Added new API endpoints for token-based email verification and resending verification emails
• Updated the EmailVerification model to include token field and removed the email field
• Modified user registration flow to send both verification code and link in emails
• Added new UI page for handling email verification via token link
• Blocked login for users with unverified emails

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 19 comments.

Show a summary per file

File	Description
server/validators/auth.ts	Added validation schemas for token-based verification and resend endpoints
server/types/auth.ts	Renamed and added type definitions for new verification methods
server/routes/auth.ts	Added routes for verify-email-token and resend-verification-email endpoints
server/models/User.ts	Added email_verified boolean field to track verification status
server/models/EmailVerification.ts	Removed email field, added token field for link-based verification
server/controllers/EmailVerificationController.ts	Added token generation and verification methods, updated email template
server/controllers/AuthController.ts	Added new verification handlers and login blocking for unverified users
server/tests/auth.spec.ts	Updated test endpoints to use new verify-email-code route
pages/verify-email/+onBeforeRender.ts	New server-side page handler to extract token from URL
pages/verify-email/+Page.vue	New UI page for token-based verification with resend functionality
pages/register/+Page.vue	Renamed VerifyEmail component to VerifyEmailForm for clarity
locales/en-us.json	Added localization strings for email verification page
components/registration/VerifyEmailForm.vue	Updated API endpoint to use verify-email-code

---

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

[Copilot]

The redirect link for unverified users points back to the login endpoint, which will likely result in an infinite redirect loop. The link should probably direct users to a page where they can request a new verification email or enter their verification code, not back to the login page that will block them again.

Suggested change

	'Go': `${SELF_BASE}/api/v1/auth/login?${redirectParams.toString()}`,
	'Go': `${SELF_BASE}/verify-email?${redirectParams.toString()}`,