Deze pagina is nog niet in uw taal. U leest de Engelse tekst.
Glossary
Browser automation
Browser automation is driving a real browser from code, so that pages open and act with nobody at the keyboard.
What a driver actually sends
A driver is a program holding one connection to a running browser and speaking to it in commands. Navigation, clicks, typing and page script all travel that single way.
- 1
It finds the browser first
A browser willing to accept commands publishes an address, and the driver reads that address before anything else.
- 2
It sends one command at a time
Each command names its target and waits for an answer, so the order of actions is the order you wrote.
- 3
It reads the page back
Text, values and pictures return over the same connection, which is how a run produces anything at all.
Your browser right now
These values are read in the browser you are reading this in. The first row is the one almost every bot check looks at first.
Uw apparaat, op dit moment
- Automation flag
- meten op uw apparaat
- User agent
- meten op uw apparaat
- Plugins reported
- meten op uw apparaat
- Processor cores
- meten op uw apparaat
Gelezen in uw browser en hier getoond. Er wordt niets verzonden.
Two places the work can live
Steps can be assembled inside the app, or your own program can drive a profile from outside. The difference is not convenience but what the browser looks like while the run happens.
Assembled in the app
Steps are picked from a fixed set of kinds and saved as a flow, and the app drives the profile itself.
Written in your own code
Your program asks the app to start a profile and attaches to the control address that comes back.
Started by something else
A timetable inside the app, or a call from your own server, begins a saved flow over the profiles you name.
What gives an automated run away
Three things betray a run and only one of them is the fingerprint. Each is read separately, so closing one leaves the other two wide open.
The automation flag
Opening a control channel makes Chromium announce that the browser is being driven, and that one value ends a check before the fingerprint is reached.
Areas switched on at connect
Parts of the protocol install hooks inside the browser that page script is able to notice, and several bot checks look for nothing else.
The behaviour itself
Straight pointer paths, identical pauses and inhuman speed are signals that no launch switch touches.
Driving a profile here
On the main engine every profile that opens gets a control address of its own, bound to this computer and reaching that one profile. It exists for exactly as long as the window does.
The address belongs to one profile
The browser writes it inside that profile's own directory at startup, and it reaches nothing outside that profile.
Handing it out is a separate choice
Your own program learns the address through the local interface, which stays off until you switch it on in the app.
Every call after that carries a credential
The app writes itself a random token on first run, and a call arriving without it gets a refusal rather than a profile.
Often confused with
A macro recorder
A recorder keeps what it watched and plays it back later. Nothing here saves your actions that way, and a flow is assembled from steps you choose.
A headless browser
Running without a window is a launch choice rather than a way of driving. The same run happens either way.
A testing framework
A framework decides what counts as a pass. The driving underneath it is the same channel whatever the verdict.
What this does not do
- It does not make a run look human. Timing, pointer paths and the order of actions are read on their own, and no launch switch touches any of them.
- It does not turn what you do into a flow. Steps are chosen from a fixed set of kinds and saved as a list, and nothing you do by hand is written into one.
- It does not reach a profile that is closed. The control address is born with the window and gone when the window is, so a script takes a fresh one at every start.
- It does not travel between computers. The address stays on the machine that opened the profile, and nothing publishes it any further.
Check it
Every line above is a file you can open and a stand that holds it.
- The client that drives a profile, and the two areas it never switches on
- apps/desktop/src/lib/cdp.js
- The automation flag is read from a real page in the real engine
- apps/desktop/test/webdriver-flag.js
- The application wide port is opened only for the engine that needs it
- apps/desktop/src/main/main.js · apps/desktop/test/cdp-port-only-when-needed.js
- The kinds of step a flow can hold, and a live run on the shipped engine
- apps/desktop/src/lib/rpa.js · apps/desktop/test/сценарий-живьём.js
Questions
- Do I need a library at all?
- No. Flows assembled in the app cover opening, waiting, clicking, typing, extracting and looping, and they run without a line of code.
- Does an automated profile look different from a hand driven one?
- It can. The flag is cleared at launch and the flow builder leaves the observable areas alone, so what is left to give you away is behaviour.
- Can a run happen without a window?
- Yes. A single run can be asked for without one, and when nothing is asked the profile's own setting decides.
- Is the control channel listening all the time?
- No. It belongs to an open profile window and disappears with it, so nothing is listening for a profile you are not using.
- What can begin a run besides me?
- A timetable inside the app, your own program through the local interface, or an assistant through the bundled server that calls those same routes.
Next to this
Assemble a flow or attach your own code
Both roads are in every build, and both drive the same profile through the same channel.