mirror of
https://github.com/benbusby/whoogle-search.git
synced 2026-04-25 04:05:57 +03:00
[GH-ISSUE #439] Using a VPN - stuck on verify page #290
Labels
No labels
Fixed (Pending PR Merge)
Stale
bug
enhancement
enhancement
good first issue
help wanted
keep-open
needs more info
pull-request
question
theme
unfortunate
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/whoogle-search#290
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @bhulk on GitHub (Sep 24, 2021).
Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/439
Deployed on MacOS latest using Docker.
When connecting a VPN and using the docker whoogle deployment it goes to the google verify you are human page and there is no way to proceed past that point.
@ghost commented on GitHub (Oct 5, 2021):
Not sure if it's as much a bug as it is Google being Google and challenging VPN/TOR traffic. That being said it'd be great to be able to specify a list of proxies and jump to a different one when verification is encountered.
@Kandelai commented on GitHub (Oct 13, 2021):
Same for me. I can't get past Google's verify using a VPN.
@bhulk commented on GitHub (Oct 13, 2021):
Would be interesting to toggle JS on and off at this point so one can proceed past this point. OR just allow JS to run on this particular page.
@bhulk commented on GitHub (Oct 13, 2021):
I see this as a bug - since there is no way to actually use Whoogle on a VPN that Google determines may be a bot or un-trusted traffic etc.
Removing JS has a definite security upside, but in this case stops the user from actually using the whoogle service altogether.
@benbusby commented on GitHub (Oct 14, 2021):
JS being disabled is just a visual issue at this point, enabling it wouldn't actually fix anything. You would just complete the CAPTCHA and then see the exact same challenge all over again.
Google's CAPTCHA check includes hostname validation, which would never work with a whoogle instance, so it's not as simple as just toggling on JS for that page. See https://security.stackexchange.com/a/151264 for an example discussion about a similar issue, and the super hacky solution that someone came up with.
Closing for now, #211 is the issue to follow for anti-captcha support (which I'm not racing to support, since the only options I've found are paid options that would only be feasible for public instances -- which Google could easily blacklist altogether on a moment's notice, rendering the entire effort pointless).
Ultimately it's an unfortunate reality with Whoogle. I've managed to get lucky and not get blocked. It seems to affect some people more than others, and I hate it, but the project is fairly powerless in this situation.
@vlfldr's idea is a possible solution as well. I'll create a separate issue for looking into that. Since I test on quite a few platforms, on my end I worked out a simple script + cron job that checks to see if any instance is blocked, and automatically spins up a new one if it is blocked. With that, I haven't seen a CAPTCHA in months. Not feasible for everyone obviously, just adding for reference.