com.bloks.www.two_factor_login.enter_totp_code, the authenticator-app code
entry of the two-factor login (Android, opened in the CDS container).
It is reached from LoginTwoFactorChooseMethodScreen.chooseAuthenticationApp()
after the person picks "Authentication app". What the person sees, as the
Android 448 app's login flow carries it: "Go to your authentication app", the
six-digit code fields with the clear-code affordance ("Clear Code text"), the
account row (" • Instagram"), 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 app's poll and
verify_code calls send should_trust_device: 0.
Its enter is the app's pair: the method selection
(method_picker.navigation.async, selected_method: totp, with the picker's
selection QPL) and then this screen's own fetch with the code-entry screen
instance the selection answer issued. The screen opens between the two calls,
exactly as the app reports it: the selection request still reports the
picker and the fetch reports the code screen. The fetch's answer issues the
verify_code QPL and the poll QPL the screen keeps running behind it; both
stay behind the screen's opaque ticket.
Its actions:
checkApproval() polls has_been_allowed once with the poll QPL this
screen's own answer issued and should_trust_device: 0, and returns
{ status: 'still-waiting' } while the login is not approved yet (the
caller decides the pace; the library never polls on its own). An approved
answer has already created the session; the action continues the process —
the platform's launch sends the post-login burst and shows the
feed, whose handle it returns. The traffic after a 2FA
approval is not known: the action sends the same post-login burst the
password login sends, and the app's own traffic
would settle it. A declined answer is
LoginTwoFactorApprovalDeclinedError, carrying the poll's answer; an answer
that issued no poll QPL is TwoFactorBloksIssuedIdMissingError.
submitCode(code) sends verify_code with challenge: totp, no masked
contact point, should_trust_device: 0, the session's x-mid as
machine_id and the screen's verify_code QPL. An accepted code embeds
the login and its session headers; the action then continues the process —
the platform's launch sends the same post-login burst
and shows the feed, whose handle it returns. A rejected
code fails with LoginTwoFactorAuthenticationAppCodeRejectedError, carrying
the brick's TwoFactorBloksInvalidCodeError; an answer that is neither an
accepted login nor the rejection marker is
TwoFactorBloksLoginResponseNotFoundError.
Only the authenticator-app branch is modelled: WhatsApp, SMS and backup codes
are not modelled.
Ships without a screenshot: producing a frame needs another account state we
do not hold.
com.bloks.www.two_factor_login.enter_totp_code, the authenticator-app code entry of the two-factor login (Android, opened in the CDS container).It is reached from • Instagram"), 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 app's poll and
LoginTwoFactorChooseMethodScreen.chooseAuthenticationApp()after the person picks "Authentication app". What the person sees, as the Android 448 app's login flow carries it: "Go to your authentication app", the six-digit code fields with the clear-code affordance ("Clear Code text"), the account row ("verify_codecalls sendshould_trust_device: 0.Its
enteris the app's pair: the method selection (method_picker.navigation.async,selected_method: totp, with the picker's selection QPL) and then this screen's own fetch with the code-entry screen instance the selection answer issued. The screen opens between the two calls, exactly as the app reports it: the selection request still reports the picker and the fetch reports the code screen. The fetch's answer issues theverify_codeQPL and the poll QPL the screen keeps running behind it; both stay behind the screen's opaque ticket.Its actions:
checkApproval()pollshas_been_allowedonce with the poll QPL this screen's own answer issued andshould_trust_device: 0, and returns{ status: 'still-waiting' }while the login is not approved yet (the caller decides the pace; the library never polls on its own). An approved answer has already created the session; the action continues the process — the platform's launch sends the post-login burst and shows the feed, whose handle it returns. The traffic after a 2FA approval is not known: the action sends the same post-login burst the password login sends, and the app's own traffic would settle it. A declined answer isLoginTwoFactorApprovalDeclinedError, carrying the poll's answer; an answer that issued no poll QPL isTwoFactorBloksIssuedIdMissingError.submitCode(code)sendsverify_codewithchallenge: totp, no masked contact point,should_trust_device: 0, the session's x-mid asmachine_idand the screen'sverify_codeQPL. An accepted code embeds the login and its session headers; the action then continues the process — the platform's launch sends the same post-login burst and shows the feed, whose handle it returns. A rejected code fails withLoginTwoFactorAuthenticationAppCodeRejectedError, carrying the brick'sTwoFactorBloksInvalidCodeError; an answer that is neither an accepted login nor the rejection marker isTwoFactorBloksLoginResponseNotFoundError.Only the authenticator-app branch is modelled: WhatsApp, SMS and backup codes are not modelled.
Ships without a screenshot: producing a frame needs another account state we do not hold.
Guide: Two-factor login