com.bloks.www.two_step_verification.entrypoint, the two-factor login's
approve-from-another-device screen (Android, opened in the CDS container).
It is the screen the login opens when the account has two-factor
authentication and the entrypoint schedules the trusted-notification poll:
the app shows it right after the login request, and it waits while the person
approves the login from a device where the account is already signed in.
Reached from LoginHomepageScreen.logIn as an ordinary screen edge, whose
credentials login either continues into the process (the feed) or returns
this screen's handle for a 2FA account; the login home stays under it, so
back() returns there and a trail records the step.
What the person sees, as the Android 448 app's login flow carries it:
"Check your notifications on another device", "Open Instagram on another
device and check the notification we sent to approve this login.", the
"Waiting for approval" state with "Approve from the other device to
continue.", a "Trust this device and skip this step from now on" toggle, and
a "Try another way" link. The toggle is not modelled: it is neither an
input nor an action, and the recorded polls send should_trust_device: 0.
Its actions:
checkApproval() polls has_been_allowed once and returns
{ status: 'still-waiting' } while the login is not approved yet (the
caller decides the pace; the app polls every ~7.5 s and the library never
polls on its own). An approved answer has already created the session; the
action then continues the process — the platform's recorded launch sends
the post-login burst and shows the feed, whose handle it returns. The
traffic after a 2FA approval is not recorded:
both recordings end at the accepting poll, so the action sends the same
post-login burst the password login sends, and a recording of that traffic
will settle it. A declined answer fails with
LoginTwoFactorApprovalDeclinedError, carrying the poll's answer.
tryAnotherWay() opens LoginTwoFactorChooseMethodScreen with this screen's
approval ticket; the picker fetches its rows from the entrypoint's issued
values and issues its own ticket for the selection.
Its enter opens the screen (the endpoint every request of the screen
reports is the CDS container with its app id). The entrypoint request and the
choice of this screen belong to the login: LoginHomepageScreen.logIn fetched
it and hands the issued poll over in the process registry, so the screen sends
no entrypoint request of its own and its values stay behind an opaque ticket.
Evidence: the Android 448 app's login flow (the entrypoint, two polls, the
approval), and the same screen with its polls behind "Try another way".
Ships without a screenshot: producing a frame needs another account state we
do not hold.
com.bloks.www.two_step_verification.entrypoint, the two-factor login's approve-from-another-device screen (Android, opened in the CDS container).It is the screen the login opens when the account has two-factor authentication and the entrypoint schedules the trusted-notification poll: the app shows it right after the login request, and it waits while the person approves the login from a device where the account is already signed in. Reached from
LoginHomepageScreen.logInas an ordinary screen edge, whosecredentialslogin either continues into the process (the feed) or returns this screen's handle for a 2FA account; the login home stays under it, soback()returns there and a trail records the step.What the person sees, as the Android 448 app's login flow carries it: "Check your notifications on another device", "Open Instagram on another device and check the notification we sent to approve this login.", the "Waiting for approval" state with "Approve from the other device to continue.", a "Trust this device and skip this step from now on" toggle, and a "Try another way" link. The toggle is not modelled: it is neither an input nor an action, and the recorded polls send
should_trust_device: 0.Its actions:
checkApproval()pollshas_been_allowedonce and returns{ status: 'still-waiting' }while the login is not approved yet (the caller decides the pace; the app polls every ~7.5 s and the library never polls on its own). An approved answer has already created the session; the action then continues the process — the platform's recorded launch sends the post-login burst and shows the feed, whose handle it returns. The traffic after a 2FA approval is not recorded: both recordings end at the accepting poll, so the action sends the same post-login burst the password login sends, and a recording of that traffic will settle it. A declined answer fails withLoginTwoFactorApprovalDeclinedError, carrying the poll's answer.tryAnotherWay()opensLoginTwoFactorChooseMethodScreenwith this screen's approval ticket; the picker fetches its rows from the entrypoint's issued values and issues its own ticket for the selection.Its
enteropens the screen (the endpoint every request of the screen reports is the CDS container with its app id). The entrypoint request and the choice of this screen belong to the login:LoginHomepageScreen.logInfetched it and hands the issued poll over in the process registry, so the screen sends no entrypoint request of its own and its values stay behind an opaque ticket.Evidence: the Android 448 app's login flow (the entrypoint, two polls, the approval), and the same screen with its polls behind "Try another way".
Ships without a screenshot: producing a frame needs another account state we do not hold.