Add multiple login support, fix Google-related login issues #72
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When the Google login got converted from OpenID to OAuth it introduced the big issue of tying the user authentication to the unreliable
User.Email
value, resulting in instances where the user changes their email and loses access to their account. Similarly, if the user was preexisting but had changed their email, their old OpenID auth claim wasn't recognized, and they too ended up with a new, incorrect account.I moved Google OAuth auth claims to the now-generic
UserAuthClaim
table to associate the login to the user independent of theUser.Email
value. I also requested the additional upgrade information in the Google auth flow to tie the new claim to an existing OpenID claim for the same account, if one exists. This is just an extension of the token request, so it comes back as information we were already requesting if we ask for it.To top things off, I refactored the login to also just allow for multiple login methods, since there wasn't really a good reason we weren't doing this before. This required some extra UI to display the multiple methods, so there's now a "My Logins" page in the user profile:
Related items on the todo list:
As a side note, the AD logins could have been worked in with this model as well, but I saw no point since it presumably works fine as-is and doesn't have the same problems referencing
User.Email
does.