Feat: prevent non work emails #3993

Mikehrn · 2025-02-16T20:43:40Z

This blocks signing up with a non-work email, as an experiment to see how it impacts our numbers. @cdriesler I gave blocking it when using single sign-on a shot, but not sure if this is correct. Please roast me if needed :D

I will leave this as a draft for now. Dont merge yet.

benjaminvo · 2025-02-16T20:51:38Z

Is this blocking only implemented on our server? I couldn't immediately see that from the code. But I guess it should.
Have you tested how it works for invites? Flow: Receive invite on a blocked email domain -> Open signup screen with the email pre-filled -> Here we probably shouldn't block.
Are you also blocking using a Google SSO button?

Mikehrn · 2025-02-16T21:02:44Z

Is this blocking only implemented on our server? I couldn't immediately see that from the code. But I guess it should.

Have you tested how it works for invites? Flow: Receive invite on a blocked email domain -> Open signup screen with the email pre-filled -> Here we probably shouldn't block.

Are you also blocking using a Google SSO button?

Yeah there is no difference now, but you're right, I'm however not sure how we can do that atm, afaik there is no isSpeckle method. Maybe we should do it with a FF?
Good point, should we block invites with blocked domains, or do we still want to allow those? In essence it's the same as signing up
I think it should capture both, but I need @cdriesler to help me validate this, as I'm not very familiar with the server part of the auth

cdriesler · 2025-02-16T21:12:03Z

What you've done to block domains on the backend is sound, but I would put the same logic within the body of createUser to capture all pathways (email/password, server-level SSO, workspace SSO, etc). Will push the change to this branch tomorrow.

How this will behave with Google SSO is that they will always be able to complete the sign in flow, but we'll prevent new user registration if the email is on the blacklist. So "chuck@speckle.systems" is ok, but "chuck@gmail.com" is not.

I'll take a look at how we can limit this set of changes to app.speckle.systems. Each server declares its "canonical URL" and I think we're safe to use that.

Mikehrn · 2025-02-16T21:20:19Z

What you've done to block domains on the backend is sound, but I would put the same logic within the body of createUser to capture all pathways (email/password, server-level SSO, workspace SSO, etc). Will push the change to this branch tomorrow.

How this will behave with Google SSO is that they will always be able to complete the sign in flow, but we'll prevent new user registration if the email is on the blacklist. So "chuck@speckle.systems" is ok, but "chuck@gmail.com" is not.

I'll take a look at how we can limit this set of changes to app.speckle.systems. Each server declares its "canonical URL" and I think we're safe to use that.

Checking canonical URL sounds easy, vs a FF which one you think makes most sense? I have local changes to add the FF if we wanna go that route 😄

benjaminvo · 2025-02-16T21:20:46Z

And remember that this is an experiment for now. So we should try to be pragmatic if there are ways to cut corners.

cdriesler · 2025-02-16T21:21:32Z

What you've done to block domains on the backend is sound, but I would put the same logic within the body of createUser to capture all pathways (email/password, server-level SSO, workspace SSO, etc). Will push the change to this branch tomorrow.
How this will behave with Google SSO is that they will always be able to complete the sign in flow, but we'll prevent new user registration if the email is on the blacklist. So "chuck@speckle.systems" is ok, but "chuck@gmail.com" is not.
I'll take a look at how we can limit this set of changes to app.speckle.systems. Each server declares its "canonical URL" and I think we're safe to use that.

Checking canonical URL sounds easy, vs a FF which one you think makes most sense? I have local changes to add the FF if we wanna go that route 😄

Probably both is good imo!

Mikehrn · 2025-02-16T21:24:06Z

And remember that this is an experiment for now. So we should try to be pragmatic if there are ways to cut corners.

FE-wise the only question is wether to block personal emails in invite or allow them, either isn't much work, it's mostly a product question

benjaminvo · 2025-02-16T21:33:27Z

And remember that this is an experiment for now. So we should try to be pragmatic if there are ways to cut corners.

FE-wise the only question is wether to block personal emails in invite or allow them, either isn't much work, it's mostly a product question

When blocking in invite would you do it in the actual invite flow or when the user tries to sign up using that email? Or both.

I'm not sure yet if blocking on invite is needed to start. I don't think so right now.

github-actions · 2025-02-16T21:34:09Z