com.bloks.www.two_step_verification.method_picker, the two-factor login's
"Try another way" screen (Android, opened in the CDS container).
It is reached two ways, both of them the app's: from
LoginTwoFactorApproveFromAnotherDeviceScreen.tryAnotherWay() when the person
declines the trusted notification ("Try another way"), and directly from
LoginHomepageScreen.logIn when the entrypoint schedules no approval poll —
the server's default is another method, so the app opens the picker right
after the login. It shows the confirmation methods the account can use
instead of the trusted notification. What the person sees, as the Android 448
app's login flow carries it: "Choose a way to confirm it’s you" with "These
are your available confirmation methods." and the rows "Notification on
another device" ("Approve the login from another device."), "Authentication
app" ("Get a code from your authentication app."), "WhatsApp" and "SMS"
("We’ll send a code to +7 *** *--55", the masked number), "Backup code"
("Use a backup code you saved."), then "Need another option?" and "See more
options".
Its action:
chooseAuthenticationApp() opens LoginTwoFactorAuthenticationAppCodeScreen.
The selection call (selected_method: totp) and the code-entry screen
fetch are that screen's own enter burst, in the recorded order: the
recording's selection request still reports this screen as the client
endpoint, and the code-entry request reports the code screen.
WhatsApp, SMS and backup codes are not exposed as actions: no recording
shows any of those flows. Their rows stay data (offeredMethods) so a caller
can see what the account offers.
Its enter brings the picker (its CDS endpoint) to front. On the login path
the login action already fetched its rows; that request is the shared flow's
and reports the entrypoint endpoint (no recording covers a non-approve
entrypoint), so the screen only reuses the issued rows. On the "Try another
way" path it fetches them after its navigation from the entrypoint-issued
screen instance: method_picker with that instance, the challenge and
is_whatsapp_installed: 0 / cloud_trust_token: null. The answer's offered
methods and the method its selection state marks preselected are the screen's
data; its selection QPL stays behind an opaque ticket. Both paths carry the
preselected method, so a UI can mark the row the app marks.
Ships without a screenshot: producing a frame needs another account state we
do not hold.
com.bloks.www.two_step_verification.method_picker, the two-factor login's "Try another way" screen (Android, opened in the CDS container).It is reached two ways, both of them the app's: from
LoginTwoFactorApproveFromAnotherDeviceScreen.tryAnotherWay()when the person declines the trusted notification ("Try another way"), and directly fromLoginHomepageScreen.logInwhen the entrypoint schedules no approval poll — the server's default is another method, so the app opens the picker right after the login. It shows the confirmation methods the account can use instead of the trusted notification. What the person sees, as the Android 448 app's login flow carries it: "Choose a way to confirm it’s you" with "These are your available confirmation methods." and the rows "Notification on another device" ("Approve the login from another device."), "Authentication app" ("Get a code from your authentication app."), "WhatsApp" and "SMS" ("We’ll send a code to +7 *** *--55", the masked number), "Backup code" ("Use a backup code you saved."), then "Need another option?" and "See more options".Its action:
chooseAuthenticationApp()opensLoginTwoFactorAuthenticationAppCodeScreen. The selection call (selected_method: totp) and the code-entry screen fetch are that screen's ownenterburst, in the recorded order: the recording's selection request still reports this screen as the client endpoint, and the code-entry request reports the code screen.WhatsApp, SMS and backup codes are not exposed as actions: no recording shows any of those flows. Their rows stay data (
offeredMethods) so a caller can see what the account offers.Its
enterbrings the picker (its CDS endpoint) to front. On the login path the login action already fetched its rows; that request is the shared flow's and reports the entrypoint endpoint (no recording covers a non-approve entrypoint), so the screen only reuses the issued rows. On the "Try another way" path it fetches them after its navigation from the entrypoint-issued screen instance:method_pickerwith that instance, the challenge andis_whatsapp_installed: 0/cloud_trust_token: null. The answer's offered methods and the method its selection state marks preselected are the screen's data; its selection QPL stays behind an opaque ticket. Both paths carry the preselected method, so a UI can mark the row the app marks.Ships without a screenshot: producing a frame needs another account state we do not hold.