IPTorrents fixes for Cloudflare #12939
Conversation
john-miller-831985
force-pushed
the
master
branch
from
70b7dac
to
95fcaba
Compare
|
Thanks for the contribution, it's always appreciated (encouraged even). However, given that these cookies from Cloudflare only last a few hours, FlareSolverr seems like a better fix for this, or just change the site link you're using to one which doesn't have the DDoS protection implemented. If there's something I'm missing here, please let me know. |
john-miller-831985
force-pushed
the
master
branch
from
95fcaba
to
ca241a5
Compare
|
@ilike2burnthing FlareSolverr is not able to work with Captchas currently so it is not helpful. I might be able to switch to an URL that is not protected, but that is only a solution if there is one not being protected. At least this small code change allows the cookie method to work with the captcha until it expires. From my testing it lasts much longer than a few hours. It has been going for the last day, but when it expires updating it will be annoying. Do you have a better long term option? And do you have any concerns with the proposed changes? In theory this might not be a long term solution, but it should not hurt anything. |
|
Ah, didn't realise they had implemented captchas, looks like you have to get your credentials wrong once for it to appear. I'll test this out shortly. |
|
Either way it isn't a big deal, I just wanted to share the solution that was working for me. And if there is anything I should change to improve the code for the project, I can always go back and make revisions. Or we can just close out the PR without merging if changing the url is the preferred solution. |
|
Using our current release (v0.20.539) I can't get the sign in to fail for https://iptorrents.com/ I've gotten my credentials wrong once to force the use of captcha, and it still worked, I've even changed the UA of the browser completely, it still accepted the cookie. Are you taking a cookie from a different device than Jackett is running on (e.g. Windows > Linux)? Do they share the same public IP address? EDIT: trying your build, I can put in the wrong UA and still sign in. |
|
I am using Firefox and noticed the user agent is hard coded to chrome. I was also using the main iptorrents url and as you pointed out the other domains work fine with the current build. I just find it much more consistent when specifying the user agent, specifically when cloud flare decides to prompt. It might be that my IP address was just unlucky the last couple of days and I have been getting the captcha. I am not sure how to force that, but I am still consistently getting them. |
|
@garfield69 are you able to cause a login failure using our current release if using a cookie with a Linux or MacOS UA on a Windows Jackett? If not, are you happy to merge this anyway? It doesn't seem to do any harm, and it may be the case that this user's IP has been marked for additional scrutiny for some reason. |
I cannot cause a failure.
Interestingly, the cookie from ubuntu has a PHPSESSID key while the one from win10 does not. Other keys come and go between attempts, __cf_bm, old-pass. Consistently present keys are cf_clearance, uid and pass. A bunch of users have had recent issues with the iptorrents indexer, but most needed to just add flaresolverr or pick a cloudflare-free iptorrents domain to get access.
yes. |
|
He He. I installed v0.20.552 over the top of my win10 and I can use the iptorrents indexer without even filling in the UA ! |
|
v0.20.555 |
Recently I noticed that Jackett had stopped working for me. After some research I noticed that it was simply from a security measure that had been put in place. This added a field to the cookie and required the user agent to be the same. Many other sites have been doing the same so I updated the code for IPTorrents to simply do the same.