Closed lanitochka17 closed 4 months ago
Job added to Upwork: https://www.upwork.com/jobs/~0183573e4ff04521ad
Triggered auto assignment to @peterdbarkerUK (Bug
), see https://stackoverflow.com/c/expensify/questions/14418 for more details.
Triggered auto assignment to Contributor-plus team member for initial proposal review - @thesahindia (External
)
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.
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:
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 validationNavigation.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 -> desktopThis 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.
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
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.
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:
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)
|| 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))
NA
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 @peterdbarkerUK, @thesahindia Huh... This is 4 days overdue. Who can take care of this?
π£ It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? πΈ
Won't be able to take this! Please reassign.
I can take over
π£ @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 π
Note on the above, @situchan is added as the reviewer
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?
@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?
- Confirm that the user is prompted to open the desktop app
I stopped here. I am not prompted to open desktop app
I stopped here. I am not prompted to open desktop app
@situchan please try with an account without 2FA as well.
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).
@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!
@peterdbarkerUK please confirm and remove Needs Reproduction
label
Triggered auto assignment to @trjExpensify (Bug
), see https://stackoverflow.com/c/expensify/questions/14418 for more details.
I'm getting the blocking screen on web:
Steps:
Now.. if I actually click the link (like most would instead of copying it), I get a different result.
Click to open desktop and land here:
Click "just sign in here" and land here to enter my 2FA code:
Enter my 2FA code and I'm signed in.
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:
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.
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:
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?
They get this one, judging by the video above in this comment:
Hmm, and the account has 2FA enabled right?
But yeah, I think its a bug. It should take them to the 2FA input screen if they have it enabled
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 I would add a note:
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) βοΈ
Hmm so the email we send from Staging Desktop links to production?
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.
πππ
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 π
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:
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.
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
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:
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.
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?
I think ideally they'd just see the the following, unless I'm misunderstand the flow:
Here is your magic code
view with the copy notifying them to enter the code where they originally requested it from. Like so:
https://github.com/Expensify/App/assets/16747822/bdfb9191-81d9-49bb-b129-d13f4ed355bf
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.
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 π
@trjExpensify @situchan this issue is now 4 weeks old and preventing us from maintaining WAQ, can you:
Thanks!
Current assignee @situchan is eligible for the Internal assigner, not assigning anyone new.
Current assignee @situchan is eligible for the External assigner, not assigning anyone new.
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?
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
@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 ?
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.
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?
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
Issue Owner
Current Issue Owner: @trjExpensify