Bij de Rust-crate headless_chrome kiest de startinstelling van de browser een HTTP-tussenpersoon. De Fetch-handler van het tabblad levert het account wanneer Chromium erom vraagt:

let proxy = "http://proxy.example:8080";
let options = headless_chrome::LaunchOptions::default_builder()
    .proxy_server(Some(proxy))
    .build()?;
let browser = headless_chrome::Browser::new(options)?;
let tab = browser.new_tab()?;

tab.enable_fetch(None, Some(true))?;
tab.authenticate(Some(proxy_user), Some(proxy_password))?;
tab.navigate_to("https://www.example.org/")?;
tab.wait_until_navigated()?;

De omringende functie geeft fouten door, en proxy_user en proxy_password zijn String-waarden uit de bestaande accountconfiguratie van de applicatie. Stel de authenticatie in voordat de navigatie de uitdaging kan uitlokken.

Het tweede argument van enable_fetch schakelt authenticatiegebeurtenissen in. Chromium beschouwt gebruikersinformatie in --proxy-server niet als deze uitwisseling van inloggegevens.

Houd de browser en het tabblad in leven voor het werk. Als er ook eigen Fetch-onderschepping is geïnstalleerd, bepaal dan wie gepauzeerde verzoeken vervolgt en wie uitdagingen beantwoordt; een onopgelost gepauzeerd verzoek kan de navigatie blokkeren.

Deze eenvoudige authenticatie op het tabblad veronderstelt de bedoelde proxy-uitdaging. Een werkstroom met authenticatie van een andere origin heeft expliciete afbakening van de uitdaging nodig in plaats van het tussenpersoonaccount voor elke server te hergebruiken. Ook Chromium's SOCKS5-beperking op gebruikersnaam en wachtwoord staat los van dit HTTP-authenticatiepad.

Gerelateerde artikelen