fix(login): wait for either 2FA input target in step_two_fa#1
Closed
Srain021 wants to merge 1 commit intoonurserce:masterfrom
Closed
fix(login): wait for either 2FA input target in step_two_fa#1Srain021 wants to merge 1 commit intoonurserce:masterfrom
Srain021 wants to merge 1 commit intoonurserce:masterfrom
Conversation
When step_select_two_fa selects a 2FA method from the dropdown, IBKR's login SPA briefly re-renders, which can remove input[placeholder*="Code"] from the DOM for a short window. The current step_two_fa path calls _find_two_fa_input_target() synchronously right after the TOTP code is generated, and that call does a point-in-time DOM snapshot without waiting. If the snapshot lands inside the re-render gap, the lookup falls back to TWO_FA_INPUT (xyz-field-bronze-response), which does not exist in the Mobile Authenticator App flow, and the subsequent wait_and_identify_trigger times out after 60s even though TOTP was generated correctly. Fix: replace the eager snapshot + lookup with a direct wait_and_identify_trigger on both TWO_FA_INPUT and TWO_FA_INPUT_GENERIC, so Selenium natively waits for whichever input is active for the flow. This removes the race without changing the selector semantics. Tested on aarch64 Linux running this fork's second-factor-selection branch: TOTP auto-entry completed on the Mobile Authenticator App flow and the session persisted across container restarts.
Author
|
Superseded by #1, per @Voyz's suggestion to keep @onurserce's contribution chain intact. Closing this one — happy to continue the review over there. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Originally opened against IBeam master as Voyz#283; redirecting here per @Voyz's suggestion so that @onurserce's contributions in Voyz#277 are preserved properly.
Problem
When
step_select_two_faselects a 2FA method from the dropdown, IBKR's login SPA briefly re-renders, which can removeinput[placeholder*="Code"]from the DOM for a short window. The currentstep_two_fapath calls_find_two_fa_input_target()synchronously right after the TOTP code is generated, and that call does a point-in-time DOM snapshot without waiting. If the snapshot lands inside the re-render gap, the lookup falls back toTWO_FA_INPUT(xyz-field-bronze-response), which does not exist in the Mobile Authenticator App flow, and the subsequentwait_and_identify_triggertimes out after 60s even though TOTP was generated correctly.Fix
Replace the eager snapshot + lookup with a direct
wait_and_identify_triggeron bothTWO_FA_INPUTandTWO_FA_INPUT_GENERIC, so Selenium natively waits for whichever input is active for the flow. This removes the race without changing the selector semantics.Tested
Tested on aarch64 Linux running this fork's second-factor-selection branch: TOTP auto-entry completed on the Mobile Authenticator App flow and the session persisted across container restarts.