IPTorrents blocked by Cloudflare

[mmenanno]

I wrote a config that should work for IPTorrents:

    "IPTorrents": {
        "url": "https://iptorrents.com/login.php",
        "login_url": "https://iptorrents.com/t",
        "login_title": "Torrents - IPTorrents - #1 Private Tracker",
        "login_box": "username",
        "login_box_type": "NAME",
        "password_box": "password",
        "password_box_type": "NAME",
        "submit_box": "//input[@type='submit']",
        "submit_box_type": "XPATH"
    }

However their Cloudflare protection seems to block the request, if anyone has a solution for that, I figured I'd preserve the config here.

[mastiffmushroom]

Seems like a potential solution may be here: https://stackoverflow.com/questions/68289474/selenium-headless-how-to-bypass-cloudflare-detection-using-selenium

Will look into this further.

[digitalgp]

https://github.com/FlareSolverr/FlareSolverr i have seen been used to integrate ARRS with the need for cloudflare proxy

[gardz]

Interesting project there @digitalgp. I tried the couple of projects in @mastiffmushroom link above (undetected-chromedriver & selenium-stealth) but couldn't get past Cloudflare unfortunately.

I'll give yours a try now :-)

[gardz]

Well there you go... FlareSolverr works a perfectly! I was able to reach the IPT login page behind Cloudflare via the FlareSolverr proxy. And the added bonus is the project looks to be very active & updated regularly, because this is likely an on going cat & mouse game that we'd probably not want to have to handle in this project... outsourcing to another project would be perfect!

Now to imbed that container alongside this one and add it into the code workflow. I'm thinking it might be good to add an extra "protection_type" variable to tracker_config.json which can be set as "cloudflare" (or in the future something else). This way we can say which trackers have protection mechanism XYZ in front and we can choose what strategy may need to be applied to get around it. In this case for IPT, protection_type=cloudflare would route the HTTP request via the users local FlareSolverr instance instead of using chromium directly.

This just means we'd need to package / have FlareSolverr as a dependent container to install along with TAL. The Dockerfile / Compose can handle this gracefully though.

[mastiffmushroom]

If you would like to submit a pull request for adding this, I will approve it. I'm a bit busy right now and don't have a way to resolve this.

[bengalih]

Here is another project which might lead to an integrated solution:

CloudflareBypassForScraping