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
: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.
Yes. Ditto for the other way around (if you're working on that bug as well).
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  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 ...  https://github.com/groovecoder/kuma/commit/ea63c511fabcd9327e325cd502e9c4c76e561928
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
You need to log in before you can comment on or make changes to this bug.