-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Captcha Killer #62
Comments
Does this require use of a 3rd party service that enters the capcha's? I can clone your version to a new dir and test using slower internet if you think it would help. |
No, it doesn't rely on third party solvers. That was my first thought, but I am to cheap for that. LOL It is a pure programming. I don't have it in my forked repository at this time. I have been testing in my local clone. I have been getting some promise errors after it runs for 4 or more hours and I am not sure if it is related to the change. |
Good news. After running all day long, I went through all 140 pages. Every captcha that was encountered was decoded successfully. :-) I will have to integrate the changes that were made today into my base code and I will issue a pull request as soon as I can. |
@jpchip , Let me know how to proceed. Thanks! |
Are you solving capcha's on the password pages as well or using another method to remove those? |
Unfortunately, this is only for the ones that popup on the sweep page itself. The ones that stop the program until the captcha it typed into Chromium. Hopefully, the work being tested by @jpchip on #58 will help. My testing with the one suggestion broke the process, so hoping there is a way to handle the cookies needed properly. |
This is very exciting. thanks! :) I will test and merge this BEFORE the config-file changes. Need to resolve #66 first, then I'll give this look. |
This has been merged into master and released (v2.9.0). I added you to the contributors list in the package.json. Thanks for your help! |
Minor issue with this. In the scenario where a capcha is asked for and tesseract supplies one but the sweep does not sucessfully "complete" for whatever reason (double box, no video, wrong type of video etc) amazon will continue to ask you for capcha's on every sweep until one is able to "finish". At one point I manually did a sweep in my OTHER browser to get amazon to stop after having to do around 20 capcha's in a row. In this circumstance it seems to treat it as if the initial capcha failed and just sits there waiting for the user to enter the 2nd capcha. Perhaps the capcha killer needs a self check to determine if it's still on the same giveaway. |
You may be on to something. I will keep my eye open for this scenario. The problem is that the testing has to occur in the wild. Plus, this is a particular setup that has to happen with a specific set of circumstances. Perhaps the data driven approach that will block going into an already entered seep may make this a moot item. I am working on #66 and if I can get that licked, a data driven approach is next on my to do. |
I believe I have found a way to address the captchas that appear from time-to-time on entries. I am testing now, but it is looking good. It may be a somewhat bandwidth intensive solution though. Not exactly sure, but it makes those captchas a thing of the past.
I will test for a few days and do a pull request if everything works as expected.
The text was updated successfully, but these errors were encountered: