feat(whitelist): add email & domain-based whitelisting for signups

[waleedlatif1]

Summary

add email & domain-based whitelisting for signups
if it is not configured, then it is ignored

Type of Change

• New feature

Testing

Tested manually by setting up a whitelist and testing with allowed & disallowed domains & emails

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
sim	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 8, 2025 6:38am

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
docs	⬜️ Skipped (Inspect)			Aug 8, 2025 6:38am

[greptile-apps]

Greptile Summary

This PR introduces email and domain-based whitelisting functionality for user authentication. The implementation adds two new optional environment variables (ALLOWED_LOGIN_EMAILS and ALLOWED_LOGIN_DOMAINS) to control which emails or domains can sign up or sign in to the application.

The feature is implemented through a middleware hook in the authentication system that intercepts sign-in and sign-up requests. When configured, it validates the incoming email against comma-separated lists of allowed emails and domains. The validation includes proper normalization (lowercase conversion and trimming) and supports both specific email address whitelisting and entire domain whitelisting.

The implementation is designed to be completely backward-compatible - if the environment variables are not set, the system ignores the whitelist checks entirely. This allows existing deployments to continue functioning unchanged while giving new deployments the option to implement access control.

The whitelist logic first checks specific email addresses, then falls back to domain checking if the specific email isn't found. This hierarchical approach allows for granular control where organizations can whitelist entire domains while still having the ability to explicitly allow or deny specific addresses within those domains.

Confidence score: 4/5

• This PR is safe to merge with low risk as it implements optional access control that doesn't affect existing functionality
• Score reflects well-structured implementation with proper error handling and backward compatibility, though lacks automated tests
• Pay close attention to the authentication middleware logic in auth.ts to ensure the whitelist validation works as expected

_{2 files reviewed, 2 comments}

_{Edit Code Review Bot Settings | Greptile}

[greptile-apps]

style: Consider using z.string().min(1) instead of just z.string() to ensure non-empty values when these variables are provided

[greptile-apps]

logic: Should validate email format before domain extraction. requestEmail.split('@')[1] could fail on malformed emails.

Suggested change

	const emailDomain = requestEmail.split('@')[1]
	isAllowed = emailDomain && allowedDomains.includes(emailDomain)
	const emailDomain = requestEmail.includes('@') ? requestEmail.split('@')[1] : null
	isAllowed = emailDomain && allowedDomains.includes(emailDomain)