Yes, I'm def going for a mixed approach. Using requests where I can, Selenium where I must.Headless raw requests are easily detected. Unless you want to write your own EMCAScript parser, I'd recommend using Selenium. This assumes you want to emulate "organic" traffic.
Headless raw requests are easily detected. Unless you want to write your own EMCAScript parser, I'd recommend using Selenium. This assumes you want to emulate "organic" traffic.
Selenium as a whole is easily detected most of the time. But I heard that you can use MultiLogin with Selenium, and control their own browsers with it.
Are you referring to selenium headless/framework or chromedriver/firefox driver? The latter 2 are actually very difficult to detect with traffic rewriting and injection since you're in full control of the browser stack.
Well, not really experienced in that, but I think that it goes together. From what I read on StackOverflow, there was some issue with some website with Selenium + Chrome Webdriver in headless mode, and the site was being able to detect there was some automation going on.
Do not run headless mode--headless mode is very easily detected. A simple test for canvas or opengl will easily detect any headless mode browsers.
What's a workaround then if one wants to not see the browser window opened?
Would running everything in Docker be a solution?
Docker doesn't render GUI as far as I know. Containerization is only for console apps.
To emulate a user, you have to behave like a user. No real "user" would ever browse in headless mode. The bottom line is you'll have to run the full browser to behave like a user. Full virtual machines can help you run multiple instances of browsers with a GUI.
I think there is a misunderstanding, I agree with you fully. Using Requests should be the first tool used due to far less resource usage. I've profiled Requests vs Selenium, and we are talking 100X more resource usage with Selenium. Plus, Selenium is cludgy to use, where reading a simple HTTP status code would suffice. I 100% prefer Requests, and would use 100% of the time if there weren't pages that require Javascript either due to rendering or fingerprinting.You have it twisted OP. That is like saying should I use this old banger of a car when I have been driving a sportscar.
Like others say selenium is a last resort and for the others saying that 'resource use isn't important' they a idiots. If your bot is 500 times more efficient then it is 500 times the earnings for the same price. And selenium resource use quickly adds up once you get in the double figures of threads. These guys who say that obviously are not proper coders.
I think there is a misunderstanding, I agree with you fully. Using Requests should be the first tool used due to far less resource usage. I've profile Requests vs Selenium, and we are talking 100X more resource usage with Selenium. Plus, Selenium is cludgy to use, where reading a simple HTTP status code would suffice. I 100% prefer Requests, and would use 100% of the time if there weren't pages that require Javascript either due to rendering or fingerprinting.
A general good rule of thumb is using requests for read-only info that is available on the public API. Anything user-based may require browser emulation, but some elements can be done via HTTP. Sure, many sites do send Telemetry data, but they have to take into account legitimate users who block the telemetry sending for privacy reasons. It's an endless game trying to outsmart the botters.Can you name one somewhat popular site that doesn't use Javascript for some sort of telemetry? If you want to emulate a user, you have to parse and handle Javascript in today's world.
If you don't care that your traffic may appear like a bot, go with requests. It really depends on your use case and you have to weight the cost/benefits of resource use vs user-like behavior.
Yep, xfvb allows virtual rendering of the browser so you don't have to run in headless mode. This was a workaround for a long time before headless came out. However, more resources are consumed, so if you don't need it, avoid it.It can if you use xfvb iirc.
Alright, that's what I was thinking. A VPS could do the job aswell then.
Selenium as a whole is easily detected most of the time. But I heard that you can use MultiLogin with Selenium, and control their own browsers with it.
Hi 夢市片, can you please clairfy on Multilogin? Do they host the VMs that the browsers run on, run them remotely, and do you get that as part of the plan? Or do you have to provide the hardware?Selenium as a whole is easily detected most of the time. But I heard that you can use MultiLogin with Selenium, and control their own browsers with it.
Hi 夢市片, can you please clairfy on Multilogin? Do they host the VMs that the browsers run on, run them remotely, and do you get that as part of the plan? Or do you have to provide the hardware?
Hi 夢市片, can you please clairfy on Multilogin? Do they host the VMs that the browsers run on, run them remotely, and do you get that as part of the plan? Or do you have to provide the hardware?
I agree with the dude above mateYou can't run extensions when Chrome is in headless mode. Also, you can't use authed proxies easily either.
No hardware is needed, everything is emulated in a browser. You create 100/1000/10000 browser profiles, assign different proxies to each (or use rotating proxies) and it's equal to having the same amount of unique computers.
You can install Multilogin on your computer or server. A single computer may run 20-30 or more browser profiles at once depending on its specs.