Change:
} if (provider === 'email') { <del> return User.findOne$({ where: { email } }) </del> <ins> return User.findOne$({ where: { email: new RegExp(email.replace('.', '.'), 'i') } }) </ins> .flatMap(user => { return user ? Observable.of(user)

Discussion:
I can't change my email address on the settings page. Anyone one else want to confirm this?
Happy to help on this - I poked around a bit and believe I've found the source of the bug. Also glad to point you in that direction if you prefer to handle this since you've already assigned it to yourself.
Sure, thing go for a PR if you have something ready.
I have a WIP PR ready - cool if I open that?
Do it you can use draft mode if it's not ready.

Describe the bug TL;DR – first signed up with GitHub (which has email # 1 set as primary). Lately changed the email on FCC to email # 2 and since then unable to log in using any of the available methods. I have two emails: .domain On GitHub, I have the first one as a primary email and the second one as a secondary. IIRC, I first signed up to FCC with GitHub, so the letters were going to my first email. Then I set my email at FCC to the second one and this is where the fun begins. What happens when I try to log in using different methods: As you can see, no method allows me to log into my original account. Email bindings shown in each of the accounts: My session cookie is still present in one of the browsers and when I try to change the email back to # 1, it says that it is already bound to another account, which is fair enough.
Does something need to be clarified? It's not a "Help" issue, it's a bug report.
What if you try to change your email to some other email - then go to the browser that's still logged in with the original account, and change the email back to - or if you're still logged in on a browser with your original account, maybe change the email to a new email and see if that will allow you on to your original account. It doesn't get to the root of the problem, but it may get you back on to your original account.
Hi Thanks for your report. Can you send me an email with details of your emails. I'll fix up your account, and investigate the root cause and possible fix there on.
I no longer have this session. I've sent an email, the subject is as the name of the issue.
I can see that we indeed have two accounts for each of your emails listed in the email. For all intents and purposes, we only use email as the primary identifier of your account. So, it literally depends on what a provider returns us as an email address to lookup and sign you into the account. For example: First email: Changed email: Scenario 1: When you sign-in through email, you must use your changed email "", using the old email will indeed create a new account for "". We do not track old emails per account as a measure of privacy.

Scenario 2: When you sign-in through social providers like GitHub, they should be returning us the changed email, or indeed it will simply create a new account for the email they returned to us. We do not bind email to social provider again for privacy reasons. Essentially by design, we will create or return an account as per the authentication method used.
Well, the thing is – there are now three accounts. The original one is .
Okay, I found the issue. Thanks for the additional information. This indeed is a validation bug, when someone changes email. So, when you entered your email on the update form in settings: You entered something like: , this was stored on our DB as is without sanitising it to lowercase. And the providers will always return lowercase emails. We unfortunately treated this incorrectly. If you are okay, I am going to delete your 'new accounts' and restore the email that you intended as per the change lower-cased, which should give you access back to your original account. As for the fix, I'll audit the code and get back to you.
I don't use them, so yeah.
thanks for confirming, I have updated the email to be lowercased on your original account and removed the new accounts. Can you test this and let me know, if it's all fixed.
Yep, it's working.
The fix for this is dependent on