Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In create_oauth, link existing email account #290

Merged
merged 1 commit into from
Aug 13, 2024
Merged

Conversation

chennisden
Copy link
Contributor

To elaborate, suppose we create an account

[email protected]
PASSWORD

in the username-password registration flow.

Before this change, if you were to use the

[email protected]

Google OAuth, then you would create a new OAuth account. This is clearly undesireable behavior.

There are two approaches we can take to address this.

  • We can reject the registration, explaining in depth that the email [email protected] is already taken by an email account. This is likely to be frustrating for the user, but it doesn't do any "sneaky action at a distance".

  • We can silently merge the email and Google OAuth accounts if we detect that there is already an account with the email [email protected]. I believe this is the better approach to take.

    This might be a worse approach in something like an online game, where people might want to have multiple, separate accounts. But RoboList does not fall into that category. For here, users are merely a set of permissions associated with a set of authentication procedures, and taking the union of both is maximally convenient for the user. So merging accounts is almost always good.

Now, there is an odd thing that can happen. If I were to register on GitHub with [email protected], and then use that to register for RoboList, and then change it on GitHub, RoboList would still be using the email [email protected]. This might be surprising for some users, but it will be fine so long as we build the settings page and are very clear to the user about what email is associated with their account.

My philosophy for the "read email from OAuth token" is merely to populate the email field with an educated guess. Because having multiple registration/login flows is always going to be a little finnicky by nature, we are not going to try and perpetually tie the user's email account with their GitHub/Google email.

@chennisden
Copy link
Contributor Author

To be clear, this should be considered as a bugfix, only that there are multiple mutually exclusive approaches one can take to fix it.

To elaborate, suppose we create an account

[email protected]
PASSWORD

in the username-password registration flow.

Before this change, if you were to use the

[email protected]

Google OAuth, then you would create a new OAuth account. This is clearly
undesireable behavior.

There are two approaches we can take to address this.

- We can reject the registration, explaining in depth that the email
  [email protected] is already taken by an email account. This is likely
  to be frustrating for the user, but it doesn't do any "sneaky action
  at a distance".
- We can silently merge the email and Google OAuth accounts if we detect
  that there is already an account with the email [email protected]. I
  believe this is the better approach to take.

  This might be a worse approach in something like an online game, where
  people might want to have multiple, separate accounts. But RoboList
  does not fall into that category. For here, users are merely a set of
  *permissions* associated with a set of *authentication* procedures,
  and taking the union of both is maximally convenient for the user. So
  merging accounts is almost always good.

Now, there is an odd thing that can happen. If I were to register on
GitHub with [email protected], and then use that to register for
RoboList, and then change it on GitHub, RoboList would still be using
the email [email protected]. This might be surprising for some users, but
it will be fine so long as we build the settings page and are very clear
to the user about what email is associated with their account.

My philosophy for the "read email from OAuth token" is merely to
populate the email field with an *educated guess*. Because having
multiple registration/login flows is always going to be a little
finnicky by nature, we are not going to try and perpetually tie the
user's email account with their GitHub/Google email.
Copy link
Member

@codekansas codekansas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dope, nice fix :)

@codekansas codekansas merged commit 913e60e into master Aug 13, 2024
2 checks passed
@codekansas codekansas deleted the dupe-email branch August 13, 2024 23:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants