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 "[email protected]" is ok, but "[email protected]" 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 "[email protected]" is ok, but "[email protected]" 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 "[email protected]" is ok, but "[email protected]" 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

📸 Preview service has generated an image.

github-actions · 2025-02-16T21:51:39Z

📸 Preview service has generated an image.

github-actions · 2025-02-17T13:48:38Z

📸 Preview service has generated an image.

github-actions · 2025-02-18T09:01:40Z

📸 Preview service has generated an image.

github-actions · 2025-02-18T09:44:51Z

📸 Preview service has generated an image.

github-actions · 2025-02-18T10:32:03Z

📸 Preview service has generated an image.

github-actions · 2025-02-18T10:40:14Z

📸 Preview service has generated an image.

github-actions · 2025-02-18T11:14:18Z

📸 Preview service has generated an image.

github-actions · 2025-02-18T12:11:36Z

📸 Preview service has generated an image.

github-actions · 2025-02-18T12:43:44Z

📸 Preview service has generated an image.

github-actions · 2025-02-18T13:21:40Z

📸 Preview service has generated an image.

packages/frontend-2/lib/auth/helpers/validation.ts

github-actions · 2025-02-19T11:47:01Z

📸 Preview service has generated an image.

iainsproat · 2025-02-26T09:15:35Z

utils/helm/speckle-server/values.schema.json

@@ -89,6 +89,11 @@
          "type": "boolean",
          "description": "Forces onboarding for all users",
          "default": false
+        },
+        "noPersonalEmailsEnabled": {


The negation (no) is tricky to decipher. Might have been better as AllowPersonalEmails or PersonalEmailsEnabled, and flip the logic internally.

Wouldn't that cause it to block personal emails on all deployments? This is an experiment we want to run briefly, maybe just a week or so, to see the results on app. For now this is not a permanent product change so should have as little impact as possible on other deployments

It should be true (i.e. existing behaviour) by default.

Ah yeah true, good morning, I don't really wanna spend too much more time on this, I think we should go with this for now, and we can improve if it this becomes a permanent change (I do agree with your point tho)

iainsproat · 2025-02-26T09:16:09Z

packages/server/modules/auth/tests/apps.graphql.spec.js

@@ -130,7 +130,7 @@ describe('GraphQL @apps-api', () => {
    ;({ sendRequest } = await initializeTestServer(ctx))
    testUser = {
      name: 'Dimitrie Stefanescu',
-      email: 'didimitrie@gmail.com',
+      email: 'didimitrie@example.org',


Nice, I like the example.org usage 👍

github-actions · 2025-02-26T09:21:26Z

📸 Preview service has generated an image.

Mikehrn added 2 commits February 16, 2025 21:33

Feat: Dont allow non-work emais

f733a6d

Throw auth error when no work email

7284e32

Mikehrn requested review from benjaminvo and cdriesler February 16, 2025 20:43

Added test

852eaf7

Added feature flag

64db24c

Dont block non work emails when valid invite token is present

d485140

fix(domains): block domains in createUser service

b0c95d2

Merge branch 'main' into mike/prevent-non-work-emails

561c3d9

Merge branch 'main' into mike/prevent-non-work-emails

0e12d24

Added FF check

157c7a0

Mikehrn marked this pull request as ready for review February 18, 2025 10:27

Mikehrn requested review from gjedlicska and andrewwallacespeckle February 18, 2025 10:32

Removed debug

563eb57

fix(emails): make tests respect feature flags

a24bfb8

fix(emails): remove gmail in tests

9ddaf00

cdriesler added 2 commits February 18, 2025 12:32

fix(emails): remove more illegal emails

da0cad0

Merge remote-tracking branch 'origin' into mike/prevent-non-work-emails

c4bb350

fix(emails): one more time

58b9a88

andrewwallacespeckle reviewed Feb 19, 2025

View reviewed changes

packages/frontend-2/lib/auth/helpers/validation.ts Outdated Show resolved Hide resolved

andrewwallacespeckle previously approved these changes Feb 19, 2025

View reviewed changes

Remove export as password rle

5349123

Mikehrn dismissed andrewwallacespeckle’s stale review via 5349123 February 19, 2025 11:41

Mikehrn requested a review from andrewwallacespeckle February 19, 2025 11:41

andrewwallacespeckle previously approved these changes Feb 19, 2025

View reviewed changes

gjedlicska previously approved these changes Feb 24, 2025

View reviewed changes

Mikehrn added 2 commits February 26, 2025 10:00

Merge branch 'main' into mike/prevent-non-work-emails

f442435

Merged main

cf25d2a

Mikehrn dismissed stale reviews from gjedlicska and andrewwallacespeckle via cf25d2a February 26, 2025 09:10

gjedlicska self-requested a review February 26, 2025 09:12

gjedlicska approved these changes Feb 26, 2025

View reviewed changes

iainsproat reviewed Feb 26, 2025

View reviewed changes

Mikehrn merged commit 2ecb981 into main Feb 26, 2025
27 of 29 checks passed

Mikehrn deleted the mike/prevent-non-work-emails branch February 26, 2025 09:55

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feat: prevent non work emails #3993

Feat: prevent non work emails #3993

Mikehrn commented Feb 16, 2025

benjaminvo commented Feb 16, 2025

Mikehrn commented Feb 16, 2025 •

edited

Loading

cdriesler commented Feb 16, 2025

Mikehrn commented Feb 16, 2025

benjaminvo commented Feb 16, 2025

cdriesler commented Feb 16, 2025

Mikehrn commented Feb 16, 2025

benjaminvo commented Feb 16, 2025

github-actions bot commented Feb 16, 2025

github-actions bot commented Feb 16, 2025

github-actions bot commented Feb 17, 2025

github-actions bot commented Feb 18, 2025

github-actions bot commented Feb 18, 2025

github-actions bot commented Feb 18, 2025

github-actions bot commented Feb 18, 2025

github-actions bot commented Feb 18, 2025

github-actions bot commented Feb 18, 2025

github-actions bot commented Feb 18, 2025

github-actions bot commented Feb 18, 2025

github-actions bot commented Feb 19, 2025

iainsproat Feb 26, 2025

Mikehrn Feb 26, 2025

iainsproat Feb 26, 2025

Mikehrn Feb 26, 2025 •

edited

Loading

iainsproat Feb 26, 2025

github-actions bot commented Feb 26, 2025

Feat: prevent non work emails #3993

Feat: prevent non work emails #3993

Conversation

Mikehrn commented Feb 16, 2025

benjaminvo commented Feb 16, 2025

Mikehrn commented Feb 16, 2025 • edited Loading

cdriesler commented Feb 16, 2025

Mikehrn commented Feb 16, 2025

benjaminvo commented Feb 16, 2025

cdriesler commented Feb 16, 2025

Mikehrn commented Feb 16, 2025

benjaminvo commented Feb 16, 2025

github-actions bot commented Feb 16, 2025

github-actions bot commented Feb 16, 2025

github-actions bot commented Feb 17, 2025

github-actions bot commented Feb 18, 2025

github-actions bot commented Feb 18, 2025

github-actions bot commented Feb 18, 2025

github-actions bot commented Feb 18, 2025

github-actions bot commented Feb 18, 2025

github-actions bot commented Feb 18, 2025

github-actions bot commented Feb 18, 2025

github-actions bot commented Feb 18, 2025

github-actions bot commented Feb 19, 2025

iainsproat Feb 26, 2025

Choose a reason for hiding this comment

Mikehrn Feb 26, 2025

Choose a reason for hiding this comment

iainsproat Feb 26, 2025

Choose a reason for hiding this comment

Mikehrn Feb 26, 2025 • edited Loading

Choose a reason for hiding this comment

iainsproat Feb 26, 2025

Choose a reason for hiding this comment

github-actions bot commented Feb 26, 2025

Mikehrn commented Feb 16, 2025 •

edited

Loading

Mikehrn Feb 26, 2025 •

edited

Loading