Skip to content
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

Closed
KryptoNova opened this issue Apr 13, 2019 · 10 comments
Closed

Captcha Killer #62

KryptoNova opened this issue Apr 13, 2019 · 10 comments
Labels
enhancement New feature or request

Comments

@KryptoNova
Copy link
Collaborator

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.

@famewolf
Copy link

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.

@KryptoNova
Copy link
Collaborator Author

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.

@KryptoNova
Copy link
Collaborator Author

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.

@KryptoNova
Copy link
Collaborator Author

@jpchip ,
I am trying to figure out what branch to do the changes for the Captcha Killer pull request. Should I wait till you merge the config-file branch into master?

Let me know how to proceed. Thanks!

@famewolf
Copy link

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.

Are you solving capcha's on the password pages as well or using another method to remove those?

@KryptoNova
Copy link
Collaborator Author

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.

@jpchip jpchip added the enhancement New feature or request label Apr 16, 2019
@jpchip
Copy link
Owner

jpchip commented Apr 16, 2019

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.

@jpchip
Copy link
Owner

jpchip commented Apr 18, 2019

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!

@jpchip jpchip closed this as completed Apr 18, 2019
@famewolf
Copy link

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.

@KryptoNova
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants