ulozto-downloader
ulozto-downloader copied to clipboard
ERROR: Cannot parse CAPTCHA image URL from the page. Changing Tor circuit.
Hi,
in last days i received error:
CAPTCHA protected download - CAPTCHA challenges will be displayed [TOR] TOR started [Link solve] TOR get new CAPTCHA (timeout 30) [Link solve] ERROR: Cannot parse CAPTCHA image URL from the page. Changing Tor circuit. [Link solve] TOR get new CAPTCHA (timeout 30) [Link solve] ERROR: Cannot parse CAPTCHA image URL from the page. Changing Tor circuit.
i tried update from 3.1.0 to 3.5.1 but still same error. till now it worked like charm. debian buster,
pip3 -V
pip 18.1 from /usr/lib/python3/dist-packages/pip (python 3.7)
tor --version
Tor version 0.4.7.13.
Thanks for great tool :)
Same problem with the newest version
same
same problem bruh i fking hope they fix this shit first vzum is dead now this bruh i hate ulozto im not gonna pay for stupid credits 🗡️
I'm working on web app frontend for ulozto-downloader and found the same issue. At first, I thought something is wrong with my integration. But it seems Ulozto implemented a new kind of protection/challenge? The page that should contain the captcha image now contains JavaScript code with some Cloudflare DDoS protection (but that's just me guessing from the parameter names I saw in the code). The idea is that bots will have a problem with interpreting JS, but the browser of the user that opens the link does it automatically. Since the downloader is using Tor, I guess it should interpret the JS just fine, so maybe it won't be that hard to fix it.
On the other hand, it's very likely that Ulozto is protecting the website only when the user's IP is from some foreign country, and in that case, I'm not sure how it could work in the past. Maybe the protection wasn't there?
Ah, I see. So Cloudflare was already covered by cloudscraper module. The cloudscraper is using JS interpreter to run the Cloudflare JS challenge code. But as @kubikaugustyn pointed out, the JS is doing a request to https://uloz.to/cdn-cgi/challenge-platform
. Maybe the cloudscraper's JS interpreter is not able execute the POST requests like that?
Just an idea - since the downloader is already using features of Tor, wouldn't be better to use it in headless mode to do these requests instead of faking the browser using the requests/cloudscraper? All these problems related to Cloudflare anti-bot protection would go away or am I wrong?
Any update, how to fix this error?
I have a same problem... Is there not solution?
Thank you!
Temporary solution is docker image mentioned here: https://github.com/setnicka/ulozto-downloader/pull/173#issuecomment-1686093671
But it is WIP!
Same problem here. Captchas were solved with no problems before the change which introduced solving captchas through Tor. Of course adding another layer on the top (Tor for captchas) for solving captchas will trigger anti-bot measures. Let the captchas be solved without Tor like before and let us all move on instead of trying to add yet another layer (Flaresolver and alikes) trying to solve the problem created by the first extra layer (Tor for captchas).
This downloader was popular among users mostly for the simplicity that it did not require many dependencies or too much effort setting it up on user's part. Adding layers upon layers of new dependencies and extra steps for the users to take just to fix something that potentionally didn't need to be fixed to begin with is simply taking this project to a wrong direction.
The functionality you are describing has been in the meantime reverted (version 3.5.2, https://github.com/setnicka/ulozto-downloader/commit/0c905f1b60c27899c76371ac9156e427e5e2ec9a) and the option --enforce-tor
introduced to control it instead.
This is however not the reason for the downloader being broken. It is Uloz.to and its Cloudflare bot protection, which has either been recently introduced or it has recently started to detect and block Tor exit IPs.
Even if the captchas are resolved from outside Tor, the download links need to be generated through Tor and this only works if we have the Cloudflare clearance cookie. The cookie can be obtained either automatically (which the FlareSolverr branch does) or we let the user providing it manually, which will be quite likely error-prone.
Better ideas (or even pull requests) are more than welcome :).
I have the exactly same problem.... any idea when this will be fixed?
My final workaround is running it like this:
File structure:
PS (SonGokussj4@mypc) - (C:\uloztodownloader) $ tree -CL 2
.
├── README.md
└── downloads
└── download.txt
In my README.md
I've got a simple guide:
NOTE:
downloads
folder in current directory (where I run the docker command) has to exist
# 1) Edit downloads/download.txt
https://uloz.to/file/DTML8nHBBdoL/arthe...0ko2D5Mt
https://uloz.to/file/ijgZqBZ9uTVA/ar...gpGWDZJLlLt
# 2) Run docker container
docker run --name ulozto-downloader -v .\downloads:/downloads pkejval/uld-docker:main
Downloaded file are in downloads
folder
Člověk si tu odloží spokojeně pěkný návod, jak to vše krásně funguje a najednou to ulož.to balí :-D To člověk nevymyslí... 😿
pravda popravdě ulož.to posledni dobou muselo dělat něco s GDPR a takovíma sračkama :D ale zase budou další stránky podle mě podobné jak uloz.to ale musím říct že nic se nevyrovná staremu dobremu uloz.to :) staré dobré časy Dne úterý 28. listopadu 2023 v 23:17:24 SEČ, uživatel SonGokussj4 @.***> napsal:
Člověk si tu odloží spokojeně pěkný návod, jak to vše krásně funguje a najednou to ulož.to balí :-D To člověk nevymyslí... 😿
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>