I Rust-craten headless_chrome vel oppstartsinnstillinga til nettlesaren ein HTTP-mellommann. Fetch-handteraren på fana leverer kontoen når Chromium ber om han:

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()?;

Den omsluttande funksjonen sender feil vidare, og proxy_user og proxy_password er String-verdiar frå den eksisterande kontokonfigurasjonen til applikasjonen. Set opp autentiseringa før navigeringa kan utløyse utfordringa.

Det andre argumentet til enable_fetch slår på autentiseringshendingar. Chromium handsamar ikkje brukarinformasjon innebygd i --proxy-server som denne utvekslinga av innlogging.

Hald nettlesaren og fana i live for arbeidet. Viss eigen Fetch-avskjering også er installert, må du definere kven som held fram pausa førespurnader og kven som svarar på utfordringar; ein uavklart pausa førespurnad kan stanse navigeringa.

Dette enkle oppsettet for autentisering på fana føreset den tiltenkte proxy-utfordringa. Ein arbeidsflyt med autentisering frå ein uvedkomande origin treng eksplisitt avgrensing av utfordringa i staden for å bruke mellommannskontoen på nytt for kvar tenar. Chromium si SOCKS5-avgrensing på brukarnamn og passord er også skild frå denne HTTP-autentiseringsvegen.

Relaterte artiklar