Closed mgrimace closed 1 year ago
Of note, I had the exact same captchas and same issue during my initial login, which was resolved using the cookie method.
Yeah, this is gonna be a long term problem. There's not a quick solution I can do to fix this. Sorry everyone.
Yeah, this is gonna be a long term problem. There's not a quick solution I can do to fix this. Sorry everyone.
No worries, and I appreciate your work!
I tried a few other things just in case: completely disconnected Pi-Holes from the network and used the default DNS for my router, then flushed my DNS cache.
This resulted in a slightly different checkout error: your purchase request is invalid, please reopen the page or try again later
.
It ultimately didn't fix the issue, but it does seem like DNS might be a factor (which I saw in the other issues thread as well).
Also getting this problem with a pi-hole on the network, Quad9 upstream, so it may have something to do with it
Yeah, this is gonna be a long term problem. There's not a quick solution I can do to fix this. Sorry everyone.
No worries, and I appreciate your work!
I tried a few other things just in case: completely disconnected Pi-Holes from the network and used the default DNS for my router, then flushed my DNS cache.
This resulted in a slightly different checkout error:
your purchase request is invalid, please reopen the page or try again later
.It ultimately didn't fix the issue, but it does seem like DNS might be a factor (which I saw in the other issues thread as well).
Also getting this problem with a pi-hole on the network, Quad9 upstream, so it may have something to do with it
Same issue. It always says "Failed to challenge captcha", even though I'm pretty sure I chose the right photos.
I noticed that you are using pi-hole. an Network-wide Ad Blocking service, coincidentally, I have also deployed AdguardHome, could it be the problem with the DNS server?
Same issue here, but without PiHole. However, I am using 1.1.1.1 as DNS instead of the one from my internet service provider. Would be surprised though if this makes a difference?!
Same issue using PiHole for my DNS.
Will be the same Problem as it was for my autoit script. directly triggering the html element/css selector causes epic to always refuse it as automation. simulating the mouse cursor and clicking on random spots at the buttons and also randomizing the mosue down + mouse up event times just fixed it. cheers
The best workaround will probably be #312. Puppeteer isn't built to dodge bot detection, so it's probably time that battle ends.
The best workaround will probably be #312. Puppeteer isn't built to dodge bot detection, so it's probably time that battle ends.
For what it's worth, I like the 'lite-mode' solution. While I can't speak for others, this would eliminate the cognitive burden of me having to routinely remember to check EPIC for free games - I don't mind losing some automation if the script's job is to gather the free games into a cart and notify me when free stuff is available to collect. That would solve my issue and is still far less burdensome than having to remember to browse the website. Is this something we do on the client end, or that you'd have to do on the backend?
I published a dev version of v5 at ghcr.io/claabs/epicgames-freegames-node:dev
. It's a pretty big change and still a WIP, but luckily any existing config should work. Your existing cookies should work as well, although I can't guarantee them forever. It uses the approach I mentioned earlier to send you checkout URLs.
In the case cookies don't work, v5 introduces device code auth, which is convenient enough to re-login from a phone even. You can view a summary of changes in #352
I published a dev version of v5 at
ghcr.io/claabs/epicgames-freegames-node:dev
. It's a pretty big change and still a WIP, but luckily any existing config should work. Your existing cookies should work as well, although I can't guarantee them forever. It uses the approach I mentioned earlier to send you checkout URLs.In the case cookies don't work, v5 introduces device code auth, which is convenient enough to re-login from a phone even. You can view a summary of changes in #352
testing v5, the login prompt works on my end, I'm also being sent the occasional purchase, however the purchase page that it is sending me is for a free game that I already purchased/redeemed manually previously.
testing v5, the login prompt works on my end, I'm also being sent the occasional purchase, however the purchase page that it is sending me is for a free game that I already purchased/redeemed manually previously.
I was able to recreate this issue by removing auth cookies completely, so I imagine something's wrong with the cookie auth. Just a few questions about your scenario to narrow it down:
I added some debug log messages in the latest commit (https://github.com/claabs/epicgames-freegames-node/pull/352/commits/384bb7352eb7a1638f78c0354d4bf37aeb29e806), and it also throws an error if there's no auth on the ownership request. That should hopefully catch the issue.
- Do you have any previous cookies that it could be using?
Yes, I used the login cookie method, I set it up previously using the current non-dev version, then switched over to the dev version.
- What is your cron schedule? Running exactly every 8 hours could cause a race condition.
Whatever the default is in the compose.yaml "cronSchedule": "5 16 * * *",
I published a dev version of v5 at
ghcr.io/claabs/epicgames-freegames-node:dev
. It's a pretty big change and still a WIP, but luckily any existing config should work. Your existing cookies should work as well, although I can't guarantee them forever. It uses the approach I mentioned earlier to send you checkout URLs. In the case cookies don't work, v5 introduces device code auth, which is convenient enough to re-login from a phone even. You can view a summary of changes in #352testing v5, the login prompt works on my end, I'm also being sent the occasional purchase, however the purchase page that it is sending me is for a free game that I already purchased/redeemed manually previously.
I did the same thing, and successfully logged in. However, I get a different screen when I click on the link to do the purchase:
I did the same thing, and successfully logged in. However, I get a different screen when I click on the link to do the purchase
The purchase URL assumes you're already logged in on the device you open it on. However, maybe there's an account id parameter I can add to the URL for a smoother login flow.
Will this method still work for multiple accounts? I have this set up for getting free games for myself and my spouse. It seems like the 2nd account is prompting me to sign out and log in as the other user:
If you set the cron schedule to run every 6 hours, you'll only have to log in once. But yes, you'll need to log in and confirm auth for the correct account you're prompted for.
However for purchases, you run into the biggest downside with this approach. If one person wants to perform the checkout for all accounts, they'll have to either set up several browsers/profiles, or re-login to each account before checkout.
testing v5, the login prompt works on my end, I'm also being sent the occasional purchase, however the purchase page that it is sending me is for a free game that I already purchased/redeemed manually previously.
I was able to recreate this issue by removing auth cookies completely, so I imagine something's wrong with the cookie auth. Just a few questions about your scenario to narrow it down:
- Do you have any previous cookies that it could be using?
- What is your cron schedule? Running exactly every 8 hours could cause a race condition.
I added some debug log messages in the latest commit (384bb73), and it also throws an error if there's no auth on the ownership request. That should hopefully catch the issue.
So, further testing, I'm getting the login prompt now semi-regularly (daily, or every other day), but no prompt to purchase/cart (for example PayDay is currently free, but it isn't being added by the bot to the cart). Using Dev version and can bring testing to that thread if you prefer.
After logging in successfully, and confirming I have a device-auths.json
file, I get a notification URL to purchase. However when I click on it, I'm redirected to the store front page.
@sam1310 moved to #353
Describe the bug
I receive a notification to solvea captcha for PURCHASE, despite solving the captcha, it gives me the error
failed to challenge captcha, please try again later
and does not complete the purchase. If I do so manaully (i.e., click the purchase button), another captcha pops up and fails in the same way.Screenshots or Logs
Configuration (please complete the following information):
Additional context
I use Pi-Hole on my system with the upstream DNS pointing to OpenDNS. I have retried above steps with Pi-Hole disabled.