Tornevall Networks

← Back to docs

Browser Automation

Language: SV | EN | SV

Browser Automation

Browser Automation är en ny admin-only-funktion i Tools för att lagra och köra browserscript direkt från Tools.

Om du vill ha en mer fokuserad steg-för-steg-guide för just hur Playwright används i projektet, se även:

Varför Playwright och inte TestCafe?

För just den här Tools-integrationen är Playwright bättre lämpat eftersom det är enklare att anropa från Laravel/PHP, fungerar väl med Chrome/Chromium/Edge, stöder persistenta browserprofiler och ger ren screenshot-/artefakthantering.

Det gör det till en mer praktisk grund för inloggningstunga sajter som Facebook än att lägga in en större fristående TestCafe-projektstruktur i Tools.

Vad funktionen kan göra

Nuvarande implementation stöder:

  • lagrade browserscript i databasen
  • projektets Playwright E2E-körningar från tests/e2e
  • körning via Chrome / Chromium / Microsoft Edge
  • standardmässiga persistenta sparade profiler för att återanvända inloggade sessioner, med valfria explicit namngivna profilkataloger
  • valfri headed eller headless körning
  • screenshots, JSON-dumpar och textartefakter under storage/app/browser-automation/
  • Playwright-rapporter och E2E-artefakter under storage/playwright/
  • direkt Run now från Tools admin
  • CLI-körning via Artisan
  • shellkörning via wrappern browserbot.sh i projektroten
  • persistenta inspelnings-/codegen-sessioner via browserbot.sh --record
  • fristående profilöppning via browserbot.sh --open
  • profilseedning/kloning via browserbot.sh --copy-profile-from ... --profile ...
  • gitvänlig export/import av profilseeds via browserbot.sh --export-profile-seed och --copy-profile-from-seed
  • cronvänlig schemalagd körning via det befintliga DB-baserade jobbflödet

Var det administreras

Tools admin:

  • /admin/browser-automation
  • /admin/browser-automation/playwright

Där kan du:

  1. skapa scriptnyckel och namn
  2. välja browser, start-URL, timeout och valfri explicit persistent profilkatalog
  3. lagra JSON-input som skickas till scriptet
  4. klistra in själva Playwright-scriptkroppen
  5. köra scriptet direkt och se senaste output/artefaktkatalog
  6. kopiera ett färdigt browserbot.sh-kommando direkt från edit-sidan när du vill starta samma lagrade script från shell

På den dedikerade Playwright E2E-sidan kan du även:

  1. se vilka filer som finns under tests/e2e
  2. läsa en vald spec direkt i admin-UI:t
  3. köra hela sviten eller en tillåten enskild testfil
  4. välja base URL, skip webserver och namn på persistent profil före körning
  5. granska sparad körhistorik med exit code, stdout, stderr, rapportlänk, screenshots, video och traces när de finns

Create/edit-sidan är nu också upplagd som ett mer guidat adminformulär:

  • en tydligare runtime-/setupsektion för nyckel, browser, profil, timeout och flaggor
  • en separat kodsektion för input-JSON och scriptkälla
  • en inbyggd snabbtest-checklista i sidokolumnen
  • ett färdigt smoke-test-script som öppnar https://example.com, loggar titeln, sparar en screenshot och returnerar strukturerad output

Serverkrav för runtime

Playwright-runnern ligger under automation/playwright och behöver sin Node-dependency installerad på servern:

cd automation/playwright
npm install

Om Chrome / Chromium / Edge inte hittas automatiskt på värden kan du sätta motsvarande server-env, till exempel BROWSER_AUTOMATION_CHROME_PATH.

För Laravel-rotens tests/e2e-runner och den aktuella SocialGPT/browserbot-stacken använder du den kanoniska installern i projektroten:

sudo bash bin/install-browserbot-stack.sh

Den installern är nu den enda stödda setup-entrypointen för den här stacken. I sin nuvarande form hanterar den de här stegen tillsammans:

  • Node.js från NodeSource
  • filtrerade apt-installationer av browserberoenden så att trasiga orelaterade PPA:er inte stoppar setupen
  • Xvfb för headed extension-playback på serverhostar
  • installation av Playwright-paketet och en projektspecifik Chromium-nedladdning under storage/app/browser-automation/playwright-browsers
  • verifiering att den unpackade SocialGPT-extensionen faktiskt finns på disk
  • en genererad .browserbot.env med säkra standardvärden för den aktuella stacken

Viktigt: den här installern är nu Chromium-först för Socdemo-runtime. Den installerar inte Google Chrome och den skapar inte längre Chrome-wrappers som primärt playbackmål. Den stödda browserkedjan för Socdemo är i stället:

  1. en verifierad riktig system-Chromium-binär när en sådan finns
  2. annars den projektspecifika Playwright-Chromium-cachen

Ubuntus snap-typ av /usr/bin/chromium-browser avvisas uttryckligen som trasig i det här flödet.

Om du vill hoppa över ett installersteg använder du installerns miljöflaggor i stället för att gå tillbaka till äldre delscripts. Exempel:

INSTALL_PLAYWRIGHT_BROWSERS=false sudo -E bash bin/install-browserbot-stack.sh

Efter installationen kan du fortfarande ladda den genererade miljöfilen innan browserbot eller socdemo körs:

cd /path/to/tools.tornevall.com
set -a
source .browserbot.env
set +a

För det aktuella Socdemo-playbackflödet är de stödda körlägena fortfarande:

SOCDEMO_DISPLAY_MODE=xvfb bash play/socdemo-play.sh
SOCDEMO_DISPLAY_MODE=visible bash play/socdemo-play.sh

SOCDEMO_DISPLAY_MODE=headless är avsiktligt blockerad för just den här SocialGPT-playbackvägen. På serverhostar är den stödda "headless"-modellen fortfarande en headed browser inne i Xvfb.

Den aktuella Playwright/Laravel-setupen förväntar sig också en modern Node-runtime (Node 18+). Om en host fortfarande exponerar en gammal/brottig Node-installation eller saknar npm/npx, kör om den enhetliga installern i stället för att försöka reparera ett delsteg manuellt:

sudo bash bin/install-browserbot-stack.sh

Installern väntar nu också på aktiva apt/dpkg-lås i stället för att falla direkt när en annan pakethantering fortfarande kör.

Om ett headful SocialGPT/browserbot-flöde senare klagar på att xvfb-run saknas, kör om den enhetliga installern i stället för att falla tillbaka till rå apt-get update på en host med trasiga tredjeparts-PPA:er:

sudo bash bin/install-browserbot-stack.sh

Playwright-steget följer nu samma princip för Linux-beroenden till browsern: det delegerar inte längre det steget till Playwrights egen råa npx playwright install --with-deps ...-väg. I stället installerar bin/install-browserbot-stack.sh de vanliga Linuxpaketen via samma filtrerade apt-wrapper först och kör därefter npx playwright install chromium för själva browsernedladdningen.

Det steget är nu också mer tolerant mot nyare Ubuntu-varianter som Nobles t64-paket och virtuella kompatibilitetsnamn. Om ett klassiskt paketnamn som libasound2 bara finns via en konkret provider som libasound2t64, löser installern det automatiskt i stället för att stoppa hela setupen på no installation candidate.

Playwright-browsernedladdningar lagras nu som standard i en projektspecifik cache under storage/app/browser-automation/playwright-browsers i stället för att vara beroende av den aktuella användarens ~/.cache/ms-playwright. Det gör browserbot, play/socdemo-play.sh och den persistenta record-hjälparen mindre känsliga för vilken Unix-användare som råkade installera browsern först.

Den projektspecifika cachen verifieras nu också aggressivare innan SocialGPT/browserbot-playback startar: installern kontrollerar att den upplösta Playwright-browserbinären faktiskt finns och är körbar, och browserbot eller socdemo kan nu reparera execute-bitar eller installera om den saknade browsern i samma cache när en tidigare nedladdning blev ofullständig.

NodeSource-delen återinstallerar också repo-konfigurationen mer defensivt på fjärrhostar: gamla nodesource.list / .sources-filer tas bort först, signeringsnyckeln skrivs till /etc/apt/keyrings/nodesource.gpg, och repot skrivs tillbaka med uttrycklig signed-by=-metadata. Det fångar den vanliga NO_PUBKEY 2F59B5F99B1BE0B4-situationen som annars lämnar apt i ett delvis brutet läge.

Om den aktuella Socdemo- eller browserbot-runtimevägen senare faller med ett fel om att den projektspecifika Playwright-browsercachen saknas eller inte går att läsa, kör om den kanoniska installern:

sudo bash bin/install-browserbot-stack.sh

Den aktuella stacken har nu två olika browserupplösningsbeteenden, och den skillnaden är viktig:

  • browserbot.sh är fortfarande den generella shell-wrappern för lagrade script, --open, --record, profilkloning och export/import av profilseeds. I den wrappern kan en begäran om chromium fortfarande falla tillbaka till en verifierad Chrome-binär när Chromium saknas.
  • play/socdemo-play.sh är nu stramare. Den defaultar till chromium, avvisar snap-typen av chromium-browser, testar system-Chromium först, sedan den projektspecifika Playwright-Chromium-cachen, och använder bara Chrome om du uttryckligen ber om det (till exempel BROWSER=chrome bash play/socdemo-play.sh).

Om en host bara exponerar chromium-browser via Snap avvisas den launchern i stället för att behandlas som en användbar browser.

Det operativa körscriptet play/socdemo-play.sh är nu självförande för själva runtime-spåret: det löser displayhantering, extension/submodul, scriptfil, runtime-profil, återställning från profilseed, avvisning av snap-stubbar och reparation av Playwright-Chromium-cachen självt innan den inspelade Playwright-filen startas direkt med node. Det använder inte längre browserbot.sh som själva playbacktransporten.

När browserbot.sh --open körs som root på en Linux-host lägger wrappern fortfarande automatiskt till Chromium-familjens no-sandbox-flaggor för just den interaktiva opensessionen. play/prepare-socdemo-profile.sh avbryter inte heller längre hela copy/export-flödet bara för att ett browser-open-steg misslyckas; om profilen redan innehöll rätt sessionsstate kan senare klonings-/exportsteg ändå fortsätta.

När samma --open --with-socialgpt-flöde startar en unpacked extension via --load-extension, lägger browserbot fortfarande till Chromes unpacked-extension-debugflaggor (--enable-unsafe-extension-debugging och --extensions-on-chrome-urls). I det sideload-läget kan Chrome Web Store fortfarande säga Installation is not enabled; det är väntat. Den praktiska verifieringen är målsajten eller extension-popupen, inte om Web Store erbjuder en installation.

För bootstrapflödet i play/prepare-socdemo-profile.sh undviker Tools fortfarande det tillfälliga sideload-tricket under själva profilförberedelsen. Source-profilen öppnas i stället på chrome://extensions/ så att du kan använda Load unpacked och faktiskt spara SocialGPT i profilen, och den senare target-verifieringen öppnas utan --with-socialgpt så playback testas mot den verkligt persistenta profilstate:n. I den prepare-/doctor-vägen är verifierad Chrome-fallback fortfarande tillåten när Chromium saknas på hosten.

Projektnivåns E2E-tester

Playwright-setupen i Laravel-roten utgår nu från:

  • config: playwright.config.ts
  • tester: tests/e2e
  • persistenta profiler: storage/playwright/profiles/<name>
  • standardfil för storage state: storage/playwright/profiles/default/storage-state.json
  • HTML-rapport/artefakter: storage/playwright/

För specs som ska behålla inloggning/session mellan körningar importerar du helpern i tests/e2e/support/persistent i stället för att importera direkt från @playwright/test.

Rootens package.json innehåller nu också ett tydligt alias:

npm run test:e2e:codegen

Om du vill använda en riktig Chromium-profil för manuell login/codegen-inspelning använder du:

bash bin/playwright-record-persistent.sh

Samma helper kan även peka mot en extern miljö:

PLAYWRIGHT_SKIP_WEBSERVER=true PLAYWRIGHT_BASE_URL=https://tools.tornevall.net bash bin/playwright-record-persistent.sh

Runtime-kontrakt för script

Det lagrade scriptet körs inne i en async-funktion och får tillgång till:

  • page
  • context
  • browser
  • playwright
  • helpers
  • input

Nyttiga helpers är bland annat:

  • helpers.log(...parts)
  • await helpers.screenshot('shot.png')
  • await helpers.saveText('note.txt', '...')
  • await helpers.saveJson('state.json', value)
  • helpers.setOutput(value)
  • await helpers.delay(ms)
  • helpers.getEnv('NAME')

CLI och cron

Kör ett lagrat script direkt via Artisan:

php artisan browser-automation:run facebook-post

Eller använd wrappern i projektroten:

bash browserbot.sh --list
bash browserbot.sh --key facebook-post
bash browserbot.sh --name "Facebook post"

Om du vill spela in/codegena Playwright-stegen innan det lagrade scriptet ens finns i databasen ännu:

bash browserbot.sh --record --key facebook-post --start-url https://www.facebook.com/

För det aktuella fb-socdemo2-stats-flödet finns också en liten genväg som startar samma record-spår med rätt profil, browser och start-URL redan ifyllda:

bash play/socdemo-record.sh

Det inspelningsläget sparar den persistenta browserprofilen i samma browser-automation-lagring som adminscripten använder, så att du senare kan sätta samma profile_directory i GUI:t och fortsätta återanvända den redan inloggade sessionen.

Om du vill öppna browsern helt för sig själv, utan playback och utan Playwright-codegen:

bash browserbot.sh --open --browser chrome --profile-directory facebook-admin --start-url https://www.facebook.com/

Om du specifikt vill att den lokala extensionen projects/socialgpt-chrome ska ligga i den delade standardprofilen för browser automation finns nu också en genväg för just det setup-steget:

bash browserbot.sh --open-socialgpt

Det öppnar riktiga Chrome, använder den persistenta profilnyckeln default, startar på chrome://extensions/ och inkluderar den lokala katalogen projects/socialgpt-chrome så att SocialGPT kan sättas upp direkt i den återanvändbara defaultprofilen.

Det läget öppnar den riktiga browserexekverbara filen med samma persistenta profile storage som senare Playwright-körningar använder.

För att undvika det vanliga fallet där en äldre sparad browserprofil öppnas igen med ett pyttelitet eller off-screen-fönster lägger browserbot.sh --open nu också på en rimlig synlig standardgeometri (1600x1000 vid 40,40) om du inte uttryckligen stänger av det.

Om du behöver justera eller stänga av beteendet på en viss host kan du använda:

export BROWSERBOT_WINDOW_SIZE=1920,1080
export BROWSERBOT_WINDOW_POSITION=20,20
# eller stäng av standardgeometrin helt
export BROWSERBOT_DISABLE_DEFAULT_WINDOW_BOUNDS=1

Om du vill förbereda flera bot-/sidkontovarianter utan att upprepa hela inloggningsflödet kan du nu klona en sparad profil till en annan innan du öppnar den:

bash browserbot.sh --clone-profile --copy-profile-from default --profile facebook-page-bot
bash browserbot.sh --open --profile facebook-page-bot --start-url https://www.facebook.com/

Det arbetsflödet är tänkt just för läget där en återanvändbar basprofil redan innehåller den dyra login-/extensions-/cookie-setupen, men där varje senare bot-/sidprofil ändå ska få sitt eget sista kontobyte eller sin egen sidspecifika sessionsstate.

Om du vill att den återanvändbara delen av en förberedd browserprofil ska följa med i Git, men utan browsercache, kan du nu exportera en cache-strippad profilseed:

bash browserbot.sh --export-profile-seed --profile facebook-page-bot --seed-name facebook-page-bot

Det skriver en återanvändbar seed under storage/app/browser-automation/profile-seeds/<seed-namn>. Den exporterade seeden är fortfarande den cache-strippade, mer commit-vänliga varianten. Vissa checkouter kan också låta fulla runtime-profiler under storage/app/browser-automation/profiles/<profil> följa med i Git, men seeden är fortfarande det smalare formatet när du vill flytta mellan hostar utan hela browsercachen/runtime-avtrycket.

Exporten behåller viktig browserprofildata som cookies, extension-state, lokal browserstate och annat login-/sessionsmaterial, men skippar cachetunga kataloger som Cache, Code Cache, GPUCache och liknande övergående browsercache.

Viktigt: profilseeden innehåller inte själva SocialGPT-extensionens källkod. När du kör browserbot.sh --with-socialgpt ... laddas extensionen fortfarande som en unpacked katalog från projects/socialgpt-chrome (eller från SOCIALGPT_EXTENSION_DIR om du explicit pekar om den). På server 2 behöver du därför både:

  • projects/socialgpt-chrome (submodulen / extension-koden)
  • storage/app/browser-automation/profile-seeds/<seed-namn> (cookies/session/local state)

På en ny värd kan du återställa runtime-profilen från den committade seeden med:

bash browserbot.sh --clone-profile --copy-profile-from-seed facebook-page-bot --profile facebook-page-bot

SocialGPT-hjälpscripten förstår nu också det arbetsflödet: play/prepare-socdemo-profile.sh exporterar automatiskt en cache-strippad seed när targetprofilen är färdig, och play/socdemo-play.sh kan återställa runtime-profilen från en matchande seed automatiskt när själva runtime-profilen saknas.

Om du är osäker på vad som saknas på en ny server kan du nu köra:

bash play/socdemo-doctor.sh

Det scriptet visar separat om det är SocialGPT-submodulen, Playwright-scriptet, runtime-profilen eller profilseeden som saknas.

Den kortare flaggan --profile är nu bara ett alias för --profile-directory, så båda dessa betyder samma sak:

bash browserbot.sh --key facebook-post --profile facebook-admin
bash browserbot.sh --key facebook-post --profile-directory facebook-admin

Om du vill att seed-kopieringen ska ske direkt före inspelning eller playback accepterar wrappern nu också --copy-profile-from tillsammans med vanliga run/open/record-kommandon. Målprofilen kopieras bara när den inte redan finns, om du inte uttryckligen lägger till --force-profile-copy.

Persistenta sparade profiler är nu standardbeteendet för lagrade script. Om profile_directory lämnas tomt i adminformuläret faller Tools nu automatiskt tillbaka till scriptets key som det scriptets sparade profilnamn. En ren temporär körning är nu specialfallet och ska begäras uttryckligen, till exempel:

bash browserbot.sh --key facebook-post --fresh-profile

För första login eller challenge-tunga körningar:

bash browserbot.sh --key facebook-post --headed

Wrappern skickar bara vidare till den lagrade DB-konfigurationen, så browserval, input-JSON, timeout och namnet på den persistenta profilen fortsätter att styras från admin-GUI:t om du inte uttryckligen override:ar dem.

Om du sedan vill att inspelning eller lagrade script ska återanvända just den SocialGPT-klara defaultprofilen, kör dem med:

bash browserbot.sh --record --profile-directory default --start-url https://www.facebook.com/
bash browserbot.sh --key fb-auto-stats --profile-directory default --headed

Schemalägg via DB-baserade jobb:

  • handler: App\Jobs\Handlers\BrowserAutomationScheduledJobHandler
  • jobbnyckel: browser_automation.run:facebook-post

Den vanliga Laravel-schedulern kör nu också jobs:run varje minut, så browserautomation kan köras automatiskt via en vanlig schedule:run-cron.

Snabbt första test

Om du vill verifiera att browserautomation verkligen fungerar innan du försöker med Facebook eller andra interaktiva sajter:

  1. öppna /admin/browser-automation/create
  2. använd en enkel nyckel som example-home
  3. låt browser vara chrome eller chromium
  4. sätt start_url (eller input.url) till https://example.com
  5. behåll det förifyllda exempelscriptet eller klistra in detta:
await page.goto(input.url || 'https://example.com', { waitUntil: 'domcontentloaded' });
helpers.log('Loaded page', await page.title());
await helpers.screenshot('example-home.png');
return {
  title: await page.title(),
  url: page.url(),
};
  1. spara scriptet
  2. klicka på Run now
  3. verifiera att:
    • senaste status blir ok
    • output visar sidans titel/URL
    • artefaktkatalogen innehåller en screenshot som example-home.png

Facebook-notis

Om du vill automatisera flöden på Facebook eller liknande sajter:

  • använd en persistent profile directory så browsern kan återanvända sin inloggade session
  • använd headed mode när du först loggar in eller när interaktiva challenges kan förekomma
  • räkna med att målplattformen ändå kan utmana, blockera eller begränsa automation

Det är just den persistenta profilkatalogen som gör att cookies/session kan bevaras mellan körningar. Om fältet är tomt använder Tools nu scriptets key automatiskt som standardnamn på den sparade profilen i stället för att falla tillbaka till en tillfällig profil.

Browserextensions tillsammans med Playwright

Det finns två olika extensionsflöden, och de fungerar inte på exakt samma sätt:

1. Chrome Web Store / Google-kontobaserad installation

Om du vill installera en extension från Chrome Web Store ska du först använda riktiga Chrome i --open-läge:

bash browserbot.sh --open --browser chrome --profile-directory socialgpt-dev --start-url https://chromewebstore.google.com/

Varför:

  • själva Chrome Web Store vägrar ofta vanlig Chromium och säger åt dig att byta till Chrome
  • Google-inloggning klagar oftare på "insecure browser/app" i automatiserade Playwright/codegen-fönster än i en vanlig interaktiv Chrome-session

Den säkrare vägen är därför:

  1. öppna den persistenta profilen med browserbot.sh --open --browser chrome
  2. logga in där manuellt om det behövs
  3. installera store-extensionen där manuellt
  4. stäng Chrome
  5. kör sedan browserbot.sh --record eller det lagrade scriptet med samma profile_directory

2. Unpacked extension från lokal katalog

Om du redan har extensionens källkod lokalt behöver du inte Chrome Web Store alls. Använd i stället unpacked-spåret:

bash browserbot.sh --open --browser chromium --profile-directory socialgpt-dev --extension-dir /path/to/project/projects/socialgpt-chrome --start-url https://www.facebook.com/

Det öppnar samma persistenta profil samtidigt som extensionen laddas direkt från den lokala katalogen.

Det här är den praktiska vägen när extensionen redan ligger i din repo och du främst vill att Playwright senare ska återanvända samma cookies/profilstatus.

Viktig begränsning

Första Google-inloggningen eller Chrome Web Store-installationen bör normalt ses som ett manuellt profilförberedelsesteg, inte som något du kan förvänta dig att playwright codegen ska klara pålitligt själv.

Eftersom Playwright senare använder samma persistenta profilsökväg kan profilens installerade extensions, cookies och browser-side-session följa med efter att du förberett dem i --open-läge.

För unpacked extensions kan browserbot.sh --open också ta en eller flera --extension-dir /path/to/extension som best-effort för manuell laddning. Det är mest användbart i headed Chromium/Chrome-sessioner. Extensionbeteende i headless-läge är generellt mindre pålitligt, så headed är säkrare när flödet är extensiontungt.

Se alltid till att användningen följer målplattformens egna regler och din egen säkerhets-/driftpolicy.