Změny v limitaci nových session z jedné IP #37
Comments
|
Jojo, nějak často to vyhazuje ty hlášky: /download-dialog/free/limit-exceeded.... |
|
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:
...a pak třetí, trapná možnost, prostě capnout počet vláken na dvou a vykašlat se na to. |
|
@JanPokorny právě jsem sem chtěl napsat něco podobného ... :-) jsem ochoten zaplatit jednorázovou vstupní poplatek $3 na testování.. :-) 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.. :-) |
|
@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...
|
|
@JanPokorny aha tak kolik stojí premium ulozto jsme neměl představu.. myslel jsem že to má cenu to API když jsi to zminoval... |
|
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/ |
|
@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... 🙏🏻 |
|
@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.) |
|
@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.. |
|
@muniv11111 Proxy byl první záměr, ale všechno co je free je děsně přetížené a nestabilní... |
Using Tor with two hops (for this purpose default 3 hops are slow without need for it). Only one download link per one Tor session to avoid 429 Too Many Connections. Solves #37
|
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 |
|
@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. |
|
@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. |
|
no co - bloknou TOR nebo v horším range request.. :D |
|
@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... 😆 |
|
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 |
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...
The text was updated successfully, but these errors were encountered: