Signup with email + password

[activatedgeek]

Thanks for this project!

Any chance we could have signup by email other than the Google account?

[steven-tey]

Will need to figure out a better way to prevent folks from signing up with a throwaway email address and adding scam/phishing links – but not opposed to adding this back in the future!

If anyone has any ideas on how to prevent this – I'm all ears! :)

[narayan-raghuwanshi]

Sending a verification link may be an option, not sure about exact implementation but will figure that out if this is the one way to implement.

[shawshankkumar]

Yes, agreed. cal.com has email verifiction now, maybe something similar can be used where people have to verify their email (otp is good, clicking on a link to verify is better)

[Autumn-Ou]

email verification links and if spam accounts are still an issue you can add some basic once every few months send an email to confirm account activity along with having some more strict process for signing up such as basic not a robot proofs.

also not email but would there be consideration to adding Apple & GitHub SSO?

[narayan-raghuwanshi]

This much tough verification will mess up whole user experience, and spam emails is not an big issue as, people uses spam emails sometimes because of trust issues with their main email. Rest it is not spam email, it is just different email.

[Autumn-Ou]

Would you consider just requiring a user to verify their email with a link sent to it as not too much of a burden for ease of use?

[steven-tey]

We had email verification via magic link before, but unfortunately folks would sign up with throwaway emails to create spam/phishing links 😅

We do have better spam filters now though so might consider reintroducing email sign ups 👀

In the meantime, if anyone wants to sign up via email feel free to send us an email at [email protected]

[ItsSVK]

Hi, To block throwaway email signups we can implement more stricter email filter. such as

1. Provide a predefined list of blocked domains for emails (not very useful, as we need to keep the list up to date periodically)
2. Instead of giving a predefined list of blocked email domains, we can use third-party APIs that will verify the domain before we proceed with the signup process.
3. Implement a way to reverify the user after some time like after a week or so. and if they are unable to verify themselves at that time, we can terminate those accounts or if they are able to verify themselves at that time, then we can consider them as genuine users and mark those accounts as verified for a lifetime.

along with these we can add more filters like rate limiting signups from same ip, adding captcha and more

[RokeJulianLockhart]

https://github.com/dubinc/dub/issues/321#issuecomment-1707169211

@ItsSVK, just don't add https://github.com/anonaddy/anonaddy.git and other well-managed e-mail address obfuscators to that list, because users like me use site-specific e-mail addresses solely to organize mail, not create throwaway accounts. See https://github.com/anonaddy/anonaddy/discussions/537#discussioncomment-7299479 for evidence.

[steven-tey]

Note: Add https://github.com/zootools/email-spell-checker for smart email validation

[steven-tey]

FWIW we just added Sign In With GitHub – courtesy of @versecafe 🥳

Planning to add email + password sign up soon – stay tuned!

[steven-tey]

@ItsSVK are there any 3rd party APIs for verifying domains that you would recommend?

[skushagra9]

I am also in to contribute

[steven-tey]

Product scope for email + password sign up:

1. Email verification (we'll need this for Google & GitHub sign in as well)
2. Backwards compatibility – some early Dub users used email magic link to sign in (no password) so the UX flow will need to account for that as well.
3. Forgot password / password reset flow

[skushagra9]

got it, I was thinking to use next-auth ?

[versecafe]

@steven-tey Any decision on how to filter out spam / throw away emails?

[steven-tey]

@skushagra9 next-auth works! @versecafe thinking if there's a 3rd party API, but if not, happy to just have a daily cron that pings this file, stores it in a Redis set, and we ping that when someone signs up via email.

[versecafe]

@steven-tey I don't think there's a great API for it or at least I haven't found one for any other projects, and anything that seems to partially support it they're all paid services.

I think daily cron to update a redis set is likely the best solution and should be performant, but a better solution would be one that lets us hit that file + add our own list of blacklisted domains in case someone makes a unique domain just to abuse the free tier and API

[versecafe]

What about pulling that file into a Vercel edge config, and then having an action for the admin panel to add additional domains?

[ItsSVK]

@ItsSVK are there any 3rd party APIs for verifying domains that you would recommend?

Hi @steven-tey , There are various 3rd party APIs/platforms which verify email authenticity. But these platforms run on freemium or paid plans. We can go with some good platforms like NeverBounce, Proofy, EmailListVerify, etc. These platforms provide APIs to verify the emails.

Still, one thing is sure, no platform, whether free or paid, can provide complete 100% solutions like accurately identifying every disposable email. However, these platforms update their disposable list periodically so that the end users get a better experience.

You can check these platforms and if you confirm I would love to work on this task.

Also, these platforms check for the complete email address validity and not only the domain part. However, if we implement an email verification feature also like sending a magic link or OTP to verify, then I believe only domain verification is good enough for us.

[versecafe]

@ItsSVK NeverBounce has no free tier, Proofy is similar it has a trial amount but no long term free tier, same with EmailListVerify, 100 checks total not monthly could work but we are also even further burdening developers and companies self hosting with another account to make, small testing limits before moving to paid

It could work but as you said email verification with the domain list could work and prevents adding yet another service to sign up for and shifting API and API keys.

[ItsSVK]

@versecafe Exactly. some of these platforms run on paid models. Some are on free initially with limited API calls and later get to paid models once free credits end.

@steven-tey @versecafe I have a suggestion to manage this problem but it might look complex a bit. Let me explain and give your thoughts.

So my idea is to maintain two files. One for whitelisted domains (eg: gamil.com, live.com, yahoo.com) and one for blacklisted domains (eg: known disposable mails). We can have daily cron to update the Redis cache.

The flow will be once user submit an email ID. We will first match it with whitelisted domains if it doesn't find any match then it'll look for blacklisted domains, if it doesn't find any match in blacklisted domains as well, in then case we'll hit the 3rd party API to check.

If the API confirms its a valid email then we'll proceed with the signup. And sends a magic link generated by the backend only to complete the signup process.

With this implementation we'll have the benefits of both worlds, offline check and online check. And I believe it'll reduce the 3rd party API calls with a significant margin, resulting in reduced API costing.

As I didn't find any complete solution/platform which detects every disposable mail perfectly with a free/paid model in my research.

[versecafe]

@ItsSVK I can definitely see the benefit of that setup, do you have a good proposal for keeping it simple for maintenance and self hosting?

[ItsSVK]

@versecafe If there is any cloud storage like Amazon's S3 or Google's GCS, we can host the file there, or as an alternative, we can keep the file in this repo/ next app as a static asset or we can host the file as a public gist in GitHub (recommended) or we can store the file data in a database also either as JSON or comma-separated String and implement an option in the admin panel to update the content in the database

as of now, I can think of these options only. meanwhile, I'll continue checking for new options, in case I get one, I'll share it here.

[versecafe]

@ItsSVK currently no storage beyond cloudinary image uploads, MySQL DB, and Redis on upstash, it could be done with Redis or Vercel edge config either would be much faster than using S3/GCP buckets, or JSON in DB and avoid needing a rebuild to adjust the list, gist is maybe but same access speed issue

[ItsSVK]

@versecafe Yes, my idea was to keep the data in the Redis cache only. The Redis data will get updated everyday once via cron. That cron will fetch the data from the statically hosted whitelist and blacklist files. We need to host these two files somewhere. Which we can host in gist for simplicity.

There will be a latency to access these gist files for sure. But that will not affect the application performance as this will execute via cron in the background.

And the end user in the frontend application will always be served via Redis cache data only. Not directly via these hosted files.

This is what my planning is actually. Am I missing something here ?

[versecafe]

@ItsSVK No that was my misunderstanding that seems to cover my concerns