createUser: mark emails as unverified on creation#46187
Conversation
|
Current dependencies on/for this PR:
This comment was auto-generated by Graphite. |
Bundle size report 📦
Look at the Statoscope report for a full comparison between the commits c94542c and 40ab277 or learn more. Open explanation
|
ab399f9 to
5a20b9f
Compare
5b40d8f to
780de03
Compare
5a20b9f to
75e7b2c
Compare
780de03 to
61aa4ed
Compare
75e7b2c to
d1a6bd6
Compare
61aa4ed to
804ed36
Compare
d1a6bd6 to
1c50b9a
Compare
804ed36 to
adf98a1
Compare
3ef8164 to
78a3acc
Compare
adf98a1 to
acdc689
Compare
IIRC, if an account is pre-created with an unverified and the user is expected to sign in via an external service, a brand new account is always created because we only consider account linking by verified emails. Not saying we can't change the current behavior, just want to call out the implication.
For a best possible UX, I believe we should. I can't recall another product that wants me to do both when I get an account... If we trust the password reset link being sent to an email, there seems no reason we can't in turn trust the email itself, right? |
unknwon
left a comment
There was a problem hiding this comment.
Minor thinking: should we keep the current behavior if SMTP is not configured?
SMTP configuration is not static - you might not set up SMTP until some time after an instance is stood up, for example. Also, whether the email is verified or not doesn't impact instances that don't have SMTP set up, since we cannot send emails anyway Update: actually, I think you may be right - a lot of other functionality (login, external accounts) key on validated emails, so retaining the old behaviour is probably best. Instances that care should set up SMTP before onboarding users
Ah, you are right. I think I'll look harder look at having the password reset also handle email verification before making this change then Update: see https://github.com/sourcegraph/sourcegraph/pull/46307 |
78a3acc to
a28f30a
Compare
467afd9 to
8bf46d9
Compare
6611218 to
6cf4633
Compare
…email_do_not_send_emails_to_unverified_emails_split
…email_do_not_send_emails_to_unverified_emails_split
|
@kopancek thanks for the first round of reviews - I've addressed your comments and updated the behaviour, would appreciate a review when you get the chance! |
mrnugget
left a comment
There was a problem hiding this comment.
Do we also need to update docs?
…email_do_not_send_emails_to_unverified_emails_split
|
@mrnugget I've created some docs around email verification here: https://github.com/sourcegraph/sourcegraph/pull/46187/commits/00d5137881812fc280f7b7265df34aadcb2e28d3 |
|
Codenotify: Notifying subscribers in CODENOTIFY files for diff 40ab277...c94542c.
|
|
Thanks! |
| The [`builtin` auth provider](../config/site_config.md#builtin-password-authentication) manages user accounts internally in its own database. It supports user signup, login, and password reset (via email if configured, or else via a site admin). | ||
|
|
||
| Password reset links expire after 4 hours. | ||
| Password reset links expire after 4 hours by default - this can be configured in site configuration with the `auth.passwordResetLinkExpiry` field. |
There was a problem hiding this comment.
I think it would be better to have a link that points to the site config schema definition here. Not sure how feasible that is though 🤔
There was a problem hiding this comment.
Trick seems to be to view the site_config page in browser, and get the anchor link through there
Co-authored-by: Milan Freml <kopancek@users.noreply.github.com> Co-authored-by: Joe Chen <joe@sourcegraph.com>

Today, users created with
mutation { createUser }automatically have their emails marked as verified, even if the email is bogus. This could cause us to automatically send potentially large numbers of emails automatically to nonexistent email addresses (see https://github.com/sourcegraph/customer/issues/1790). To mitigate this, this change marks the emails of created users as unverified if SMTP is configured.This has implications for Cloud instances, where
mutation { createUser }is frequently used to create initial admin users. After this change, these users may receive a more limited set of emails (i.e. https://github.com/sourcegraph/sourcegraph/pull/46184) and have limited capabilities (i.e. unable to link account via external service) until they verify their email by:setUserEmailVerifiedmutation or UITest plan
I've added new unit tests that cover the old and new set password behaviour on the mutation.
Manual test:
sg start, configured with SMTP indev-privatetestuserwith emailtestuser-> emails -> primary email is unverified