Enhancement: Update Waiting Logic to handle Cloudflare#9
Open
Binary-Ape wants to merge 2 commits intotechinz:mainfrom
Open
Enhancement: Update Waiting Logic to handle Cloudflare#9Binary-Ape wants to merge 2 commits intotechinz:mainfrom
Binary-Ape wants to merge 2 commits intotechinz:mainfrom
Conversation
*Overview*
The current method of verifying if the Captcha is solved is to wait an arbitrary amount of time then re-check for the elements.
Changing this to wait for the success criteria with a timeout using the original value. Allowing solving to happen faster if things go smoothly.
**Turnstile**
This had a bug in it where it would always return as successful as the `success` element is technically always there - it is just hidden.
Changing the logic to grab that element and wait for it to become visible.
**Challenge Page**
Change this to wait for a new `load` event - so when the page re-directs it will then check to see if the iFrames are there.
The `on("load")` event triggers when the event next fires.
**shadow_root.py** Changed this to use the `element_handle`.`wait_for_celector` so that it will auto wait for a selector to appear in the shadow root instead of looping with an arbitrary wait time inbetween. Since a document can have multiple shadow roots we will kick off a task to all await at the same time and break when we find the turnstile. This could be enhanced to handle multiple turnstiles with a flag to check if we should break on the first element or not. **solve_by_click.py** Modified the steps to merge Click and Validate into one process as `turnstiles` and `interstitial` have different success criteria. They both still wait asynchronously with different triggers (page reloading vs `success` element becoming visible). Broke the click_checkbox into a separate function to keep it clean as that is shared code between both solving styles.
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.
Overview
Currently the code waits an arbitrary amount of time (default:
6 seconds) and then re-check for the success criteria. This slows down the solving process if the page or turnstile returns more quickly then that.Changing the logic to wait for an event that should allow it to check sooner based on when we get a response.
Not sure if we want to update/change the variable from the
solve_click_delayto something that is more accurate on its description -solve_success_timeoutpossibly?Cloudflare - Turnstile
This had a bug in it where it would always return as successful as the
successelement is technically always there - it is just hidden.Changing the logic to grab that element and wait for it to become visible. The original checkbox disappears completely from the DOM - so there could be a check to see if it is there:
Cloudflare - Challenge Page
Change this to wait for a new
loadevent - so when the page re-directs it will then evaluate if the action was successful.The
on("load")event triggers when the event next fires - so it will only happen if a new event fires (and doesn't check the current page state)