-
-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an alternative way to pass in login cookies (fully headless support) #16
Comments
Just did a test run by copying a local logged-in
e: missing shared libs, investigating |
Unfortunately I don't think I will have any free time in the near future to add this feature into the app itself. But you should be able to transfer cookies to your server by running app on your computer, logging in and then copying chromedata/Default/Cookies file to your server. |
Thanks for the response! And the program really works quite well, locally :) Unfortunately, it looks like simply copying existing cookies over isn't quite enough; they get cleared by Patreon. I can only assume Patreon IP-restricts existing sessions. Perhaps the only alternative is a Puppeteer-controlled login with credentials passed via CLI or file, though of course that has the downside of needing to handle credentials. If you're willing to take such an implementation as a PR, I might look at doing one later, as time permits. I think I may try X-forwarding for the initial login. FWIW, if anyone else is seeing Chrome fail to launch early in the process, the following libraries were missing on a clean-ish Ubuntu container:
Running |
I don't think the issue is with patreon cookies. Their cookies are not ip-restricted unless they have changed something within last few months. But the api has some really annoying cloudflare bot protection and the problem might be that your server's ip and/or user agent triggers it, in that case you need to solve their challenge page somehow before you can do anything. CLI-based login procedure doesn't sound like something that is going to be easy to implement as it should be able to support recaptcha interaction, but if you are willing to work on it I will be more than happy to accept PR as long as there are no issues with code quality. |
Ah, that's quite likely too. In that case maybe nothing for it but X-forwarding to manually solve the captcha. Obviously trying to automate through a captcha isn't going to be easy or robust. |
FWIW, I handle this with a full-fledged headless Chrome instance and remote debugging. The process I'd suggest is:
You'll then have a fully logged-in chromedata, created headlessly, so with the same IP and whatnot. However I haven't found PuppeteerSharp (upon which PatreonDownloader is built) to be very reliable running headless, it always has issues, so I made a modification that connects it to the headless Chrome browser. I've found this much more reliable, flawless even. |
@bobobo1618 That is a really interesting way of getting around this issue. Thank you for information about this, I will consider integrating the ability to connect to remote browser in the next version. |
0.9.4 now has support for remote browser. Refer to docs/REMOTEBROWSER.md for additional information. |
I would like to run this completely headlessly on a server. Unfortunately, it doesn't look like that would work, since the current auth flow logs in via a Chrome browser window.
Would it be possible to accept the login cookies via CLI arg, or otherwise allow fully headless usage?
The text was updated successfully, but these errors were encountered: