fix(settings): Navigate to confirmation if we don't have the recoveryKey

[jonalmeida]

Because

• We can sometimes get into a point where the page is unloaded after a new
  recovery key is created. We want to gracefully handle this flow since
  the user is already verified.

This pull request

• We navigate to /reset_password_confirmed if we don't have the recovery key anymore in the SensitiveDataClient.

Issue that this pull request solves

Closes: FXA-10869

Checklist

Put an x in the boxes that apply

• My commit is GPG signed.
• If applicable, I have modified or added tests which pass locally.
• I have added necessary documentation (if appropriate).
• I have verified that my changes render correctly in RTL (if appropriate).

Screenshots (Optional)

n/a

Other information (Optional)

Built on top of #18136. Will rebase when the prior PR lands.

[vpomerleau]

I'm wondering if we should lift the check for sessionToken and uid out of the navigateNext function and above the check for recoveryKey - if that data is not in local storage then we might as well go directly to signin

[jonalmeida]

Oh, that's a good idea! It would cancel out the password-reset-with-recovery-key flow but that is probably okay if we don't have these bits needed to get started in the first place which they would reach eventually after all when it's too late.

EDIT: So I tested this out and it doesn't seem super useful - since we have already reached a verified and recovered state, I don't think we need to lift it there.

[vpomerleau]

This was a few weeks ago, so I'm no longer sure if this line previously used navigateNext or if I just had a general observation about the session token check in the navigateNext function and couldn't directly comment on the unmodified line.

The general thought was that if we reach this page without a sessionToken, we should immediately redirect to signin on render

[jonalmeida]

Yeah, that logic makes sense to me and it would have been nice if we could have early navigated without the gnarliness.

[jonalmeida]

I'm facing a weird bug with this patch where the page refreshes to a blank one first, but a second refresh does what I want. I'm not sure if this is a bug with my local config or not.

I thought it might have been because a duplication in our routes, but it seems like that is unrelated.

[vpomerleau]

I think you might be on the right track - while the route definitions in fxa-content-server include both /reset_password_verified and /reset_password_confirmed, the one we currently use in the React app is /reset_password_verified. The doubling in content-server might be an artifact from previously having different views for these routes (before my time on the team).

Using reset_password_confirmed with a React Router navigation bumps out of the React app and that's likely causing the blank page you initially see, unless you also have the same issue when navigating to /reset_password_verified

[vpomerleau]

Following up on the blank page issue - changing the route to /reset_password_verified doesn't fully resolve the issue.

However moving the navigation into a useEffect hook as follows seems to work:

  useEffect(() => {
    if (!recoveryKey) {
      // If we get here, that means a password reset was completed (with a verified account).
      // Along the way, we have lost a copy of the recovery key in memory if the page was unloaded.
      // This is fine - we navigate to the confirmed page and carry on.
      navigateWithQuery('reset_password_verified', { replace: true });
    }
  }, [recoveryKey, navigateWithQuery]);
  
  if (!recoveryKey) {
    return;
  }

[jonalmeida]

Following up on the blank page issue - changing the route to /reset_password_verified doesn't fully resolve the issue.

However moving the navigation into a useEffect hook as follows seems to work:

  useEffect(() => {
    if (!recoveryKey) {
      // If we get here, that means a password reset was completed (with a verified account).
      // Along the way, we have lost a copy of the recovery key in memory if the page was unloaded.
      // This is fine - we navigate to the confirmed page and carry on.
      navigateWithQuery('reset_password_verified', { replace: true });
    }
  }, [recoveryKey, navigateWithQuery]);
  
  if (!recoveryKey) {
    return;
  }

Thank you!

[vpomerleau]

Thanks for the updates here!

[jonalmeida]

I filed this bug where desktop needs to properly handle the URI correctly since we are fixing this bug now: https://bugzilla.mozilla.org/show_bug.cgi?id=1941390