Změny v limitaci nových session z jedné IP

JanPokorny commented 3 years ago

Alert, zdá se že změnili algoritmus podle kterého dostane IP adresa soft-ban a nové sessions vyžadují ReCaptchu. Zdá se že to už není 2 sessions / 1 minuta. Ostatní můžete zkusit jak vám to jede a reportovat, možná to protáhli na 2 minuty nebo tak...

muniv11111 commented 3 years ago

Jojo, nějak často to vyhazuje ty hlášky: /download-dialog/free/limit-exceeded....

JanPokorny commented 3 years ago

Ten nový limit se zdá být per-file, a je poměrně přísný (je to netriviální počet minut). Prostě dostanete ReCaptchu pokud se vaše IP adresa daný soubor během posledních X minut nejméně dvakrát pokoušela stáhnout.

Napadají mě v zásadě dvě možnosti jak to řešit:

Nechat uživatele opisovat ReCaptchu (https://stackoverflow.com/questions/55493536/how-to-deal-with-the-captcha-when-doing-web-scraping-in-puppeteer)
- ...případně dát možnost ji outsourcovat na nějakou z "$3/1000x ReCaptcha" služeb (to je reálná cena, právě jsem koukal), ale přijde mi to v zásadě k ničemu varianta pro program jehož jediný smysl je "být zadarmo"
Použít více IP adres (proxy servery?), dle mých experimentů to vypadá že stahovací link jde předat mezi IP adresami (a to i když z něj jedna už začala stahovat a pak uzavřela spojení), za předpokladu že to je stejná session (cookies)

...a pak třetí, trapná možnost, prostě capnout počet vláken na dvou a vykašlat se na to.

muniv11111 commented 3 years ago

@JanPokorny právě jsem sem chtěl napsat něco podobného ... :-) jsem ochoten zaplatit jednorázovou vstupní poplatek $3 na testování.. :-) to ruční zadávání stojí taky za pokus.. možná by nebyly špatné obě dvě možnosti.. s tím že kdo by chtěl rychle stahovat s auto captcha, by si zaplatit a sám by si zadal koupený API key na 1000 (klidně i víc 😉) řešení captcha.. U toho ručního (G-recaptcha-response expires in 120 seconds) tam se neobejdu bez druhého headless prohlížeče jestli to chápu dobře a tím pádem provoz na serveru kde jedu nyní s auto-captcha by takhle nešel řešit?

Jinak je zajímavé, že jak se to tu trochu rozproudilo hned na uloz.to hodili tohle. :D Náhoda? :D Asi to bude neknečný boj s větrnými mlýny.. :-)

JanPokorny commented 3 years ago

@muniv11111 Troufnu si tvrdit že to bylo spíš kvůli Vžum, to má tisíce uživatelů. Nicméně platit $3 za 1000 captcha se mi nelíbí, protože je to moc práce na to aby finální výsledek byl cca stejný jako si rovnou koupit Ulož.to premium. V ten moment mi fakt nepřijde morální (nakolik je toto slovo ironické v kontextu webu založeného na sdílení copyrighted materiálu) platit bandě Indů ve sklepě místo toho webu který používáme...

$3 => 1000 kódů => při 100 vláknech 20 souborů
99 Kč => 25 GB kredit => při 1 GB na soubor 25 souborů

muniv11111 commented 3 years ago

@JanPokorny aha tak kolik stojí premium ulozto jsme neměl představu.. myslel jsem že to má cenu to API když jsi to zminoval... a co teda to ruční zadávání? bylo by to složité? pracné na zadávání? popravdě mi moc není jasné z toho odkazu jak by to fungovalo... jinak já jsem rád že mi jede s auto-captcha na serveru.. no a dvě vlákna ono se to stáhne pomalu.. sice to nebude vžum rychlé no..

JanPokorny commented 3 years ago

Slavnostně hlásím že jsem našel řešení a je v tento moment live ve Vžum. (@setnicka take note)

Spočívá v použití Toru pro navázání počátečního spojení (získání cookies, odevzdání captchi, získání stahovacího URL), jeho následném přerušení (je potřeba explicitně přerušit a počkat cca 2s, jinak si Ulož.to myslí že session stahuje víc souborů) a navázání mimo Tor. Vlákna startují po dvojicích, mezi nimiž (a při chybě) se mění circuit.

Pro Python bych asi použil tohle: https://github.com/torpyorg/torpy/

muniv11111 commented 3 years ago

@JanPokorny vím že to tu není o vžum a omlouvám se, ale čím to může být.. vypadá že to stahuje ale skáče mi tohle nejde to vykliknout hned je to zpět...

https://pasteboard.co/JBScoZQ.png

a s tím TOREM - jen aby to vydrželo... 🙏🏻

https://blog.torproject.org/changes-tor-exit-list-service

JanPokorny commented 3 years ago

@muniv11111 Shit, to jsem rozbil já při refactoringu, zapomněl jsem že v portable verzi není shell napojení 😆 Brzo bude fix, v tento moment to můžeš opravit tím že použiješ tu verzi co se instaluje. (Bug reporty mi příště můžeš napsat na email v patičce webu.)

Jo, jsem si vědom toho že "zablokovat Tor" je z jejich strany funkční řešení. Stejně tak by bylo funkční řešení přestat free účtům posílat Range header, ale to už 5 let neudělali... (Uvažoval jsem proč. Netuším. Stahovací server má k dispozici session a je schopen poznat zda daná session už stahuje. Tedy je mimo mě proč nedovede poznat zda daná session pochází z free účtu.)

muniv11111 commented 3 years ago

@JanPokorny jo dík nenapadlo mne že na webu máš i mail.. :D ale tak šla by použít nějaká jiná proxy s rotováním IP pak třeba, když by padl TOR ne? to range header třeba mne taky zaráží.. u webshare, které mne se svým pluginem pro kodi zajímá víc... si s range header u free nečuchnu..

JanPokorny commented 3 years ago

@muniv11111 Proxy byl první záměr, ale všechno co je free je děsně přetížené a nestabilní...

setnicka commented 3 years ago

Vyřešeno fungujícím způsobem přes Tor ve verzi 1.7.1.

Tak teď začněmě odpočítávat, než zase zavedeou další věc, na kterou bude potřeba se adaptovat :D

JanPokorny commented 3 years ago

@setnicka V kódu v komentáři tam říkáš něco o 429 co myslím úplně není pravda, 429 ti pošle stahovací server když ze stejného odkazu někde někdo už stahuje. Tím že stáhneš jen jeden link přes jedno tor spojení to nenapravíš -- je tam klíčové to HTTP spojení přes tor ukončit a chvíli počkat (ve Vžum mám 2s) než uděláš nové standardní spojení na ten stejný download link.

setnicka commented 3 years ago

@JanPokorny To neodpovídá tomu, co jsem o tom vypozoroval já. Když jsem přes stejné Tor spojení získal dva různé stahovací linky (a pak klidně tohle Tor spojení zavřel a mezitím navazoval nové), tak druhý v pořadí vždycky dostal 429... i když jsem před nastartováním zkoušel různě dlouhé čekání.

Vzhledem k rychlosti navazování dvou-hopového Tor spojení mi pak přišlo zbytečné řešit to víc a mám jedno Tor spojení pro jeden download link.

muniv11111 commented 3 years ago

no co - bloknou TOR nebo v horším range request.. :D

JanPokorny commented 3 years ago

@setnicka Ukončit spojení přes Tor trvá nějakou dobu (a afaik pokud jen odpojíš circuit, tak bude ještě chvíli tomu HTTP spojení mezi exit node a Ulož.to trvat než si to uvědomí), takže to může být tím že to první už se zavřelo a to druhé to ještě nestihlo. A teď když měníš Tor circuit pokaždé, tak tam to čekání vlastně implementuješ takto... 😆

vladodriver commented 3 years ago

Limit je nyní 30 minut od posledního použití páru (IP && url_souboru). Pokud se daný pár (IP && url_souboru) nepoužije po dobu >= 30 minut, je limit uvolněn (důkladně otestováno), jinak se resetuje na 30 minut od tohoto posledního užití. Každý zbytečný pokus tedy blokuje další uživatele stejné TOR adresy a stejného souboru. Po vypršení lze znovu jen 2x. Je tedy dobré linky ukládat do cache souboru a při re-downloadu použít znovu, když mají platnost >= 2hodiny před vypršením (platí 48 hodin). Vše a mnoho dalšího (např. jednosouborové stahování ala torrent) jsem implementoval: v Opravy chyb zrychlení a vylepšení #50

setnicka / ulozto-downloader

Změny v limitaci nových session z jedné IP #37