When the user arrives on the registration page a second time, MDN forgets that they had a matching account

RESOLVED FIXED

Status

Mozilla Developer Network
Sign-in
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: openjck, Assigned: groovecoder)

Tracking

Details

(Reporter)

Description

3 years ago
Steps to reproduce:

1. Log into MDN with a GitHub account that has never been used
   to log in before, but that is backed by an email address that
   matches a Persona account that /has/ been used to logged in
   before.
2. On the registration page, notice the text that explains that
   a matching account was found.
2. On the registration page, click "Yes, connect with..."
3. Sign in with a Persona account that has never been used to
   sign in before.

Actual result:

The user arrives back at the registration page, but there is no longer text explaining that a matching account was found. In other words, MDN forgot what service the user tried to log in with in step 1.

Screencast: http://www.screencast.com/users/openjck/folders/Default/media/84133298-8f54-40b5-b56f-11534ba66ac6

Expected result:

The user arrives back at the registration page, and there is still text explaining that a matching account was found. The link "Yes, connect with..." is also shown. This is needed to address the following requirement: https://bugzilla.mozilla.org/show_bug.cgi?id=1054558#c1
(Assignee)

Comment 1

3 years ago
:shobson - I think we want to do this here ...

When user signs in with GitHub and clicks connect to an existing account, but chooses and un-matched Persona, we should go back to the registration page with a, "We couldn't find an MDN profile matching that Persona" message.
Flags: needinfo?(shobson)
Yes. Ditto for the other way around (if you're working on that bug as well).
Flags: needinfo?(shobson)
(Assignee)

Updated

3 years ago
Assignee: nobody → lcrouch
(Assignee)

Comment 3

3 years ago
To let the user "connect" an account via the signup page, allauth puts the first sociallogin attempt (e.g., GitHub) into the session and redirects to the sign up page.

When the user clicks "connect" with another social provider (e.g., Persona) on this page, allauth creates another sociallogin attempt for it. If the 2nd sociallogin matches an existing user, it kicks into a "login" that can get the 1st sociallogin out of the session, and the 2nd sociallogin from the request.

But, if there's an error - e.g., un-matched user - allauth replaces the 1st sociallogin attempt (e.g., GitHub) in the session with the 2nd sociallogin attempt (e.g., Persona), and re-directs back to the sign up view - effectively clearing out the original attempt.

To get in front of this behavior, I added code to KumaSocialAccountAdapter.pre_social_login [1] that detects when a request login doesn't match an existing account AND there's a pending login in the session, and redirects back to signup without clearing the 1st login from the session.

This does what we want - it sends the user back to the signup page with the same messaging and I can add an additional message saying we couldn't find a match for the 2nd login attempt.

But, since there's some heavy session manipulation here, I'll want to do some extensive QA and spot-checking that we don't accidentally throw any users into session/login limbo.

Pull Request incoming ...

[1] https://github.com/groovecoder/kuma/commit/ea63c511fabcd9327e325cd502e9c4c76e561928

Comment 4

3 years ago
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/53c2fc92f25e3087905f473b1a0396456940e790
fix bug 1063830 - detect unmatched login in pre_social_login

redirect mis-matched social logins

send user back to signup with error message

https://github.com/mozilla/kuma/commit/97045adeff52ead86fbf6b091b598585af9326ab
bug 1063830 - fix and add pre_social_login tests

https://github.com/mozilla/kuma/commit/d945edd76d85a95468f6eab1bcf121448bf4d625
Merge pull request #2751 from groovecoder/connect-with-unmatched-persona-1063830

fix bug 1063830 - detect unmatched login in pre_social_login
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
See Also: → bug 1291892
You need to log in before you can comment on or make changes to this bug.