[C+ payment required, Situ out until May] [HOLD for payment 2024-04-03] [$500] Desktop - Login - Unable to enter the 2FA code or exit the opened screen on desktop

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 1.4.23-0 Reproducible in staging?: Y Reproducible in production?: Y If this was caught during regression testing, add the test name, ID and link from TestRail: Email or phone of affected tester (no customers): Logs: https://stackoverflow.com/c/expensify/questions/4856 Expensify/Expensify Issue URL: Issue reported by: Applause - Internal Team Slack conversation:

Action Performed:

Prerequisites: User must be logged into web app as User A.

1. Launch the Desktop app
2. Enter an email for an existing account with 2FA (User b)
3. Go to the email inbox and locate the magic code
4. Copy the Magic link and modify it to staging
5. On the web, open a new tab and navigate to the staging magic link
6. Confirm that the user is prompted to open the desktop app
7. Click on the "Open app" option

Expected Result:

When the desktop is launched by the magic code link, it glitches, briefly shows a skeleton and then returns to the first login screen

Actual Result:

When the desktop is launched by the magic code link, there's just a blocker screen asking to enter the magic code, with no field and no option to exit the screen

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• [ ] Android: Native
• [ ] Android: mWeb Chrome
• [ ] iOS: Native
• [ ] iOS: mWeb Safari
• [ ] MacOS: Chrome / Safari
• [x] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/f07d7998-7fff-41b6-9f79-6dc2ef507cbd

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0183573e4ff04521ad
• Upwork Job ID: 1744794019492372480
• Last Price Increase: 2024-03-06
• Automatic offers:
• situchan | Contributor | 28115507

Issue Owner

Current Issue Owner: @trjExpensify

[melvin-bot[bot]]

Job added to Upwork: https://www.upwork.com/jobs/~0183573e4ff04521ad

[melvin-bot[bot]]

Triggered auto assignment to @peterdbarkerUK (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot[bot]]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @thesahindia (External)

[ikevin127]

Proposal

Please re-state the problem that we are trying to solve in this issue

When the desktop is launched by the magic code link via web - desktop prompt, we see a 2FA blocker screen asking to enter the magic code, with no field and no option to exit the screen.

What is the root cause of that problem?

The root cause of this happening stems from within ValidateLoginPage/index.website.tsx where there is no logic that specifically handles the 2FA login flow on the desktop app (where there's no multi-tab functionality like on web).

For example the flow on web goes as follows:

• we input the email for login
• the UI changes showing us the magic code input
• we click the magic code link from the email
• a new tab opens rendering the same 2FA screen telling the user to input their 2FA code in the tab where the magic code input was showing previously before opening the magic link, tab which now shows the input for the 2FA code

What changes do you think we should make in order to solve the problem?

My solution is to create a desktop specific library @libs/desktopTwoFactorRedirect/index.desktop.js (with index.js noop) where we perform the following check and pop the stack:

if ((autoAuthState === CONST.AUTO_AUTH_STATE.NOT_STARTED || autoAuthState === CONST.AUTO_AUTH_STATE.JUST_SIGNED_IN) && !isSignedIn) {
    Navigation.isNavigationReady().then(() => Navigation.resetToHome());
}

Notes:

• autoAuthState === CONST.AUTO_AUTH_STATE.NOT_STARTED to cover for edge case of when autoAuthState is not initialized yet (after logout)
• autoAuthState === CONST.AUTO_AUTH_STATE.JUST_SIGNED_IN confirms that we passed the magic code step of the login process which is one of the conditions that if true we're shown the 2FA screen
• !isSignedIn confirms that we're not signed-in yet as there's one last step and that's the 2FA validation
• calling newly added Navigation.resetToHome() when above conditions are true will pop the navigation stack to home causing the user to then be navigated to the 2FA code validation screen, autocompleting the magic code since we opened the magic code deep-link (prompt) from web -> desktop

This will handle both 2FA / non-2FA login flows when transitioned from web -> desktop.

The lib function will take in as arguments autoAuthState and isSignedIn and will be called at the bottom of the first useEffect inside the ValidateLoginPage/index.website.js component, right after this line (magic code validation call is performed) which is an important step in order for the login flow to work on desktop for both 2FA and non-2FA accounts.

Videos

MacOS: Desktop (+ edge case flow fix)

https://github.com/Expensify/App/assets/56457735/7d429304-1d87-4ac2-895f-292ab662f7ba - edge case flow https://github.com/Expensify/App/assets/56457735/c9b3ac7c-f9df-4a79-9a1b-89a53f5e314b

[tienifr]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When the desktop is launched by the magic code link, there's just a blocker screen asking to enter the magic code, with no field and no option to exit the screen

What is the root cause of that problem?

By design here, we don't want to prompt opening the desktop app for magic link

(The autoAuthState === CONST.AUTO_AUTH_STATE.NOT_STARTED condition, can check this PR for more info)

The problem here is that when the magic link is opened for the first time, autoAuthState is not available yet, the prompt to open desktop was made, then it becomes not-started after being initialized here. So the root cause is we're evaluating whether to show the open-in-desktop prompt before the autoAuthState is available.

What changes do you think we should make in order to solve the problem?

If we're on the magic link route and the autoAuthState is not available, early return here because we don't have enough information to evaluate if we should prompt yet (the magic link state is not initialized).

Later once it's initialized, the useEffect will run again and it will evaluate correctly based on the updated autoAuthState value.

So the steps are:

• Here

  const isMagicLink = CONST.REGEX.ROUTES.VALIDATE_LOGIN.test(window.location.pathname);

  (same condition we're already using in here, can extract to an util method for easy reuse)

• Here, change || autoAuthState === CONST.AUTO_AUTH_STATE.NOT_STARTED to

  || autoAuthState === CONST.AUTO_AUTH_STATE.NOT_STARTED || (isMagicLink && !autoAuthState)

  or

  || (isMagicLink && (!autoAuthState || autoAuthState === CONST.AUTO_AUTH_STATE.NOT_STARTED))

What alternative solutions did you explore? (Optional)

NA

[ikevin127]

Updated proposal

• updated solution if to account for the edge case where autoAuthState === CONST.AUTO_AUTH_STATE.NOT_STARTED (after logout) which would still cause the 2FA screen lock

[melvin-bot[bot]]

@peterdbarkerUK, @thesahindia Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot[bot]]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[thesahindia]

Won't be able to take this! Please reassign.

[situchan]

I can take over

[melvin-bot[bot]]

📣 @situchan 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link Upwork job Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻 Keep in mind: Code of Conduct | Contributing 📖

[peterdbarkerUK]

Note on the above, @situchan is added as the reviewer

[peterdbarkerUK]

Hmmm, I can't reproduce this: the link takes me to the desktop app and successfully logs me in. @ikevin127 @tienifr @situchan are you able to reproduce?

[tienifr]

@peterdbarkerUK I can still reproduce the issue same as described in the OP. Can you share a screen video of the behavior you're observing after following the same steps as in the OP?

[situchan]

6. Confirm that the user is prompted to open the desktop app

I stopped here. I am not prompted to open desktop app

[tienifr]

I stopped here. I am not prompted to open desktop app

@situchan please try with an account without 2FA as well.

[ikevin127]

I stopped here. I am not prompted to open desktop app

This is the 'blocker screen' you should see on the desktop app once transitioned to it from web - if following the steps and opening the magic link (adding staging to it) and clicking the 'Open New Expensify' once the prompt shows, while using a 2FA account.

I can still reproduce this on latest staging (v1.4.33-3).

MacOS: Desktop

https://github.com/Expensify/App/assets/56457735/c6068798-6694-4387-a03a-a39666ed63ae

[melvin-bot[bot]]

@peterdbarkerUK @situchan this issue is now 3 weeks old. There is one more week left before this issue breaks WAQ and will need to go internal. What needs to happen to get a PR in review this week? Please create a thread in #expensify-open-source to discuss. Thanks!

[situchan]

@peterdbarkerUK please confirm and remove Needs Reproduction label

[melvin-bot[bot]]

Triggered auto assignment to @trjExpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[trjExpensify]

I'm getting the blocking screen on web:

Steps:

1. Sign-out of both desktop and web
2. Sign-in on web, prompted for magic code
3. Go to email
4. Copy the URL and modify to "staging."
5. Blocking 2FA page appears.

[trjExpensify]

Now.. if I actually click the link (like most would instead of copying it), I get a different result.

1. Sign-out of both desktop and web
2. Sign-in on web, prompted for magic code
3. Go to email
4. Click the link
5. Land on this page and prompted to open desktop

6. Click to open desktop and land here:

   

7. Click "just sign in here" and land here to enter my 2FA code:

   

8. Enter my 2FA code and I'm signed in.

[ikevin127]

Thanks for looking into this! ✌

This looks like a pretty rare edge case on Desktop. I can only reproduce this with the production desktop app installed and changing the magic link to staging.

As for using the production magic link while having the staging desktop app installed - seems to work as expected as per your latest comment.

The blocking screen on web is expected IMO as when somebody with 2FA attempts login on web and clicks the magic link, this opens a new window where we see the 2FA blocking screen - this assumes you still have your initial tab open where you attempted login - where now you have to introduce the 2FA code since that's what the blocking screen in the other tab is telling you.

Finally, even though this Desktop issue can be hard to reproduce - if we want to block the 2FA flow for Desktop app then my colleague's solution would do.

Otherwise, if we want to allow the 2FA flow on Desktop then my proposal still stands. It will allow the 2FA flow for users on the desktop app via the web prompt - users will be able to go through with it as on Desktop there's no new tab functionality like on web - so it has to happen within the desktop app like demonstrated in the solution's result video:

MacOS: Desktop

https://github.com/Expensify/App/assets/56457735/7d429304-1d87-4ac2-895f-292ab662f7ba

[trjExpensify]

Thanks, @ikevin127. If you use the production desktop app and a production magic link, does everything work okay?

[ikevin127]

@trjExpensify Unfortunately no 😞 I just tried what you suggested on latest production (version 1.4.35-7) and it reproduces exactly as the OP suggests.

MacOS: Desktop

https://github.com/Expensify/App/assets/56457735/29fef450-d242-43f2-bfc9-9081028491cc

[trjExpensify]

Ah okay, cool. @NikkiWines @johnmlee101 you folks were close to this implementation, perhaps you can help us with what's expected here?

Summary of steps to repro:

1. User has 2FA enabled
2. User has the desktop app installed (signed out).
3. User goes to the desktop app to sign-in, gets sent a magic link on email
4. Clicks the link in the email and gets taken to NewDot on web
5. Clicks the modal prompt to switch to desktop
6. Gets hit with the 2FA full page blocking form

[johnmlee101]

I'm not sure if we officially support that flow since we expect the user to enter the code manually rather than click the link, but I also think it would be nice to support this case. However, between 4. and 5. are they presented with the 2FA screen on web as well?

[trjExpensify]

They get this one, judging by the video above in this comment:

[johnmlee101]

Hmm, and the account has 2FA enabled right?

[johnmlee101]

But yeah, I think its a bug. It should take them to the 2FA input screen if they have it enabled

[trjExpensify]

For the avoidance of doubt, don't suppose you could type out the steps like here, so we can follow exactly what's expected?

[johnmlee101]

1. User has 2FA enabled
2. User has the desktop app installed (signed out).
3. User goes to the desktop app to sign-in, gets sent a magic link on email
4. Clicks the link in the email and gets taken to NewDot on web
5. Clicks the modal prompt to switch to desktop 6. Desktop is presented with the 2FA Code input screen 7. User enters 2FA code 8. User is now taken into the authenticated product on Desktop.

[ikevin127]

@johnmlee101 I would add a note:

• make sure that the environment matches web / desktop app

Meaning if 2FA account attempts login from production desktop app then clicking on the email magic link directly is ok as the link will start with https://new.expensifi.com...

On staging (web / desktop app), the staging. should be appended to the email magic link before navigating to it and getting the prompt (as mentioned in the OP) ✌️

[johnmlee101]

Hmm so the email we send from Staging Desktop links to production?

[NikkiWines]

All the magic code links direct to prod, I believe - regardless of whether the request is initiated on staging web, staging desktop, prod web, prod desktop, etc.

[ikevin127]

🐌🐌🐌

Correct!

If I'm not mistaking, when we get the magic link email it's always the production domain link.

This can lead to confusion when trying to reproduce this issue as can be seen in the comments above 😅

[NikkiWines]

Thanks, @ikevin127. If you use the production desktop app and a production magic link, does everything work okay?

@trjExpensify Unfortunately no 😞 I just tried what you suggested on latest production (version 1.4.35-7) and it reproduces exactly as the OP suggests.

Given this behavior, it seems to me it's for sure a bug. We should do one of the following:

• Ensure we don't block the user from entering their 2FA code (via one of the proposals from above, if still applicable)
• Don't prompt the user to open the desktop app when using a magic link. Looking back on when we first implemented this we specifically avoided linking to the desktop app in this scenario.

As a bonus, we should probably fix the links on the backend so that they point to the appropriate environment and don't need to be manually modified to work on staging. That's out of scope for this issue though.

[johnmlee101]

Don't prompt the user to open the desktop app when using a magic link. Looking back on when we first implemented this we specifically avoided linking to the desktop app in this scenario.

Ohhhhh thanks for the context forgot all about that. Yeah Desktop support in this way was never explicitly made when we were developing for this for a reason

[trjExpensify]

If we do one of these:

We should do one of the following:

• Ensure we don't block the user from entering their 2FA code (via one of the proposals from above, if still applicable)
• Don't prompt the user to open the desktop app when using a magic link. Looking back on when we first implemented this we specifically avoided linking to the desktop app in this scenario.

... won't they still run into this:

1. User has 2FA enabled
2. User has the desktop app installed (signed out).
3. User goes to the desktop app to sign-in, gets sent a magic link on email
4. Clicks the link in the email and gets taken to NewDot on web
5. Does not get prompted to go to the desktop app, but nevertheless, hits this screen minus the prompt and can't authenticate:

[NikkiWines]

Does not get prompted to go to the desktop app, but nevertheless, hits this screen minus the prompt and can't authenticate:

Hmm, I tested this using prod just now and wasn't blocked on authenticating. They should have the field to manually enter the magic code in the desktop app at this point.

[trjExpensify]

Not sure I'm following haha. We're talking about doing away with the desktop modal prompt. So they wouldn't get prompted to head over to the desktop app. What would they see on Web where we send them via the email link they clicked?

[NikkiWines]

I think ideally they'd just see the the following, unless I'm misunderstand the flow:

• On web, they'd get the Here is your magic code view with the copy notifying them to enter the code where they originally requested it from.
• On desktop, they'd see the view for entering the magic code.

Like so:

https://github.com/Expensify/App/assets/16747822/bdfb9191-81d9-49bb-b129-d13f4ed355bf

[trjExpensify]

Cool yeah, same page! So I think we're taking a pretty big leap of faith that a person who lands on the magic code form on web will instinctively know to switch over to the Desktop app. It's a pretty confusing message given that it is the same device they requested on, right?

So the prompt to switch to Desktop when installed is actually quite helpful to reorientate them in that regard. To the point where I'm wondering if it's a better experience to make this work.

[NikkiWines]

Hhm yeah, the copy could be better for sure. I personally don't think it's too disruptive for the user but I'm also totally down with us fixing the flow so that the deep link to desktop works 👍

[melvin-bot[bot]]

@trjExpensify @situchan this issue is now 4 weeks old and preventing us from maintaining WAQ, can you:

• Decide whether any proposals currently meet our guidelines and can be approved as-is today
• If no proposals meet that standard, please take this issue internal and treat it as one of your highest priorities
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[melvin-bot[bot]]

Current assignee @situchan is eligible for the Internal assigner, not assigning anyone new.

[melvin-bot[bot]]

Current assignee @situchan is eligible for the External assigner, not assigning anyone new.

[trjExpensify]

but I'm also totally down with us fixing the flow so that the deep link to desktop works 👍

Okay cool, @ikevin127 do you want to update to reflect that and then @situchan can review?

[allgandalf]

I don't have the full context of this issue but i request to put it on hold in favour of https://github.com/Expensify/App/pull/35359 if this both are related, We migrated the files to typescript and the PR will be merged in coming days

[ikevin127]

@trjExpensify Sure, I can handle this. I'd say the RCA and solution of my proposal are the same, will fix the issue just as discussed.

Is there something I'm missing - that you suggest adding to my current proposal ?