Ga naar de inhoud

Deze pagina is nog niet in uw taal. U leest de Engelse tekst.

Glossary

Playwright

It was built for testing and is used far beyond testing. Attaching it to an antidetect profile works here, and the part worth knowing beforehand is what the attachment itself shows a page.

Playwright is an open library that drives Chromium, Firefox and WebKit browsers from one set of commands.

What the library covers

One set of commands reaches three browser families, and the same script exists in several languages. Waiting is built into each step rather than left to you.

  • Three engine families

    Chromium, Firefox and WebKit answer the same commands, so a script written once moves between them.

  • Several languages

    The same commands exist for JavaScript, Python, Java and C sharp, so picking a language is not picking a tool.

  • Waiting instead of sleeping

    A step holds until the element it needs is there, which turns a slow page into a slow run rather than a failed one.

Attaching it to a profile here

A profile here is not a browser the library started, so the library attaches instead of launching. The app opens the profile and answers with the address to connect over.

  1. 1

    Switch the local interface on

    It stays off until you do, and the app screen then shows the address and the token your script needs.

  2. 2

    Ask the app to start a profile

    The answer carries a socket address belonging to that one profile, on the main engine.

  3. 3

    Connect over that address

    The library attaches to a browser already running, and the pages already open are the pages it sees.

Your browser right now

These are read in the browser you are reading this in. A driven browser reports the first row as true unless the launch clears it.

Uw apparaat, op dit moment

Automation flag
meten op uw apparaat
User agent
meten op uw apparaat
Languages
meten op uw apparaat

Gelezen in uw browser en hier getoond. Er wordt niets verzonden.

What attaching costs you

The library switches two observable areas on the moment it connects. Those areas install hooks inside Chromium that page script is able to notice.

The flow builder inside the app never switches them on, so a profile it drives looks like a profile worked by hand.

Say it before the site does

This is the honest cost of using an outside library against a site that looks for it. If the site you work with checks for those hooks, assemble the sequence in the app instead and keep the library for the rest.

Running without a window

A run can be asked for with no window at all, which is what a script on a server wants. When nothing is asked, the profile's own setting decides.

The engine still presents itself as an ordinary browser, because the identity string is set at launch rather than derived from the mode.

Often confused with

  • Puppeteer

    The older Node library, aimed at Chromium, and it attaches here by the same road.

  • A test runner

    The runner decides what counts as a pass. The driving underneath it is the same channel whatever it decides.

  • The flow builder here

    The builder assembles steps inside the app, drives the profile itself and leaves the observable areas alone.

What this does not do

  • It does not ship with ARMANOS. You install the library yourself, and nothing in the app downloads it, updates it or pins its version.
  • It does not launch our engine for you. The app opens the profile with its fingerprint and its proxy already in place, and the library attaches to what is running.
  • It does not hide what it switches on. Two observable areas go on at connect, and a site that looks for them will find them.
  • It does not reach a profile that is closed. The address is created with the window and gone with it, so a script asks for a fresh one at every start.

Check it

Each claim above is a file you can open and a stand that runs.

The worked examples that start a profile and connect to it
apps/web/test/страница-автоматизации.js
The route that starts a profile and answers with its address
apps/desktop/src/lib/local-api.js · apps/desktop/test/local-api-gate.js
Where a profile publishes its address and how a driver picks it up
apps/desktop/src/lib/forkPage.js
The app's own driving, and the two areas it never switches on
apps/desktop/src/lib/cdp.js

Questions

Which address does it connect over?
The one the profile publishes when it opens. The app hands you that address in its answer to a start request, and it belongs to that profile alone.
Does the app have to be running?
Yes. The address belongs to an open profile window, and the local interface that hands it out lives inside the app.
Can it drive Firefox or WebKit profiles here?
No. Profiles here run on a Chromium engine, so only that family of the library is in play. The other two are for browsers we do not build.
Will a site see that the library is attached?
It can see the hooks the library installs at connect. The name of the tool is not something the channel itself reports.
Can a run start without a window?
Yes. The start request takes that as a one time ask, and it is accepted both in the body of the call and in the address.

Start a profile and attach to it

Switch the local interface on, start a profile from your script, and connect over the address that comes back.