Signed in user can not confirm their account

[mariha]

These are possibly two related issues or one.

Scenario 1.

I created an account from Facebook iPhone app (link from a comment). Something went wrong during the registration, I got an error.
Then I opened WTMG site in Chrome, tried to register but got a message the email is already in use - means the account was created.
Went to login and could login without issues but:

• When I go to the Account page, the page hangs out. I can’t do anything but close the tab.
• When I go to the Chat page, there is a message that I have to verify my email first
• I did not get verification email
• There is no link to re-send verification email to me, as the Account page is blank.

Scenario 2.

1. I created an account (using different email then in scenario 1) and get verification email. After clicking confirmation link in the email, I was taken to WTMG page where I could see green message indicating that the account is confirmed. The message disappeared and a progress bar on the page stopped moving just before the end. Blank page kept loading. Looks like request to https://welcometomygarden.org/account?confirmed=true was waiting for a response.
2. I opened WTMG page in another tab, my account was still not confirmed.
3. Went back to confirmation email, clicked again the link, the green message appeared and I refreshed a page as requested.
4. I can see my account is confirmed and works, others could give up after first attempt is unsuccessful.

[archived-m]

Thanks a lot for the detailed description @mariha, while I can't immediately reproduce the issue, we've had reports like this in the past. We need to look at state transitions between signed in/verified/signed out more clearly and especially at how they tie into routing.

My hope is that in the refactor we're doing soon, this problem will fix itself, especially since we'll be more explicit about which states the application can be in. Keeping this open for now and will revisit after the state refactor!

[th0rgall]

Email verification issues have been plaguing us since at least this issue was filed. I took a deep look at it during the last days.

Scenario 1

It's possible that some changes in 2021 have resolved scenario 1. I haven't tested it specifically with the Facebook iPhone app in-app browser, but in scenarios that I've tested over the last months, this hasn't happened, nor did we get more issue reports about this.

Something went wrong during the registration, I got an error.

Scenario 2

We got many reports about this scenario. I have been able to reproduce a version of this scenario locally, and I fixed that version in this commit: d3d5305 - I hope this fixes all verification issues we've had, and I will close this issue until we see another related issue report.

Here is some explanation of what I changed:

I was taken to WTMG page where I could see green message indicating that the account is confirmed

For many people the verification flow worked (and Michiel wasn't able to reproduce the issue above). The /auth/action route used by staging/production verification flows indeed should have properly verified accounts.

onAuthStateChanged => onIdTokenChanged

There was one catch: if you created an account in tab A, and then clicked the email verification link which opens a new wtmg app instance in tab B, then the app in tab A would have been left with an outdated state, until you refreshed the page or logged out/logged in. This is because email verifications don't trigger onAuthStateChanged.

Now we listen to onIdTokenChanged to capture when email verifications happened in all active apps: d3d5305#diff-135da8b11c910e156d8b780cf4bed7e145c8fbfef8f225437e400e3a5a6ede1eR42

Improved speed & reliability
The verification process also took long. If people closed the page when the applyActionCode was completed, but the token was not .reload()ed or token force-refreshed yet, it could lead to several states that are inconsistent, and situations like:

I opened WTMG page in another tab, my account was still not confirmed.

Now we check for which exact state we are in on every auth state change (login, logout, token change, ...), and we try to take the necessary actions from that state, without depending on the one-off successful execution of the auth/action. For example, the notification for successful verification is now fired from onIdTokenChanged.

Additionally, I removed several redundant .reload() calls that slowed down the process, so it should lessen the chances of it failing by a user navigating away & stopping JS execution.

Other bugs resolved

There were several other bugs that had been affecting us when testing locally (for example, we could never create or update gardens in environments with an app running locally). These bugs were related to verification too: if getIdToken(true) wasn't run in a local environment (but on another domain, like staging.welcometomygarden.org, as was configured for the development verification emails), then the local environment would be in another inconsistent state:

d3d5305#diff-135da8b11c910e156d8b780cf4bed7e145c8fbfef8f225437e400e3a5a6ede1eR70-R83

It's possible for Firebase to tell you that emailVerified is true on a user, while the authentication token claim email_verified is false. The latter is used for Firestore Security Rules checks, and lead to the above weird bugs (the user is actually verified in Firebase Auth, on the frontend, but not according to the Firestore).

The changes above now force refresh the token whenever we notice that we are in an inconsistent state, fixing these issues.

---

More optimizations are possible (server-side verification would be nice!), but this hopefully is already a big improvement.