Bei der Rust-Crate headless_chrome legt die Starteinstellung des Browsers einen HTTP-Vermittler fest. Der Fetch-Handler des Tabs liefert das Konto, sobald Chromium danach fragt:

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

Die umgebende Funktion reicht Fehler weiter, und proxy_user sowie proxy_password sind String-Werte aus der vorhandenen Kontokonfiguration der Anwendung. Richten Sie die Authentifizierung ein, bevor die Navigation die Challenge auslösen kann.

Das zweite Argument von enable_fetch schaltet Authentifizierungsereignisse ein. Chromium behandelt Benutzerinformationen in --proxy-server nicht als diesen Anmeldeaustausch.

Halten Sie Browser und Tab für die Arbeitslast am Leben. Wird zusätzlich eine eigene Fetch-Interception installiert, legen Sie fest, wer pausierte Anfragen fortsetzt und Challenges beantwortet; eine unaufgelöste pausierte Anfrage kann die Navigation blockieren.

Diese einfache Tab-Authentifizierung setzt die beabsichtigte Proxy-Challenge voraus. Ein Ablauf mit fremder Origin-Authentifizierung braucht eine ausdrückliche Eingrenzung der Challenge, statt das Vermittlerkonto für jeden Server wiederzuverwenden. Auch die SOCKS5-Beschränkung von Chromium bei Benutzername und Passwort ist von diesem HTTP-Authentifizierungspfad getrennt.

Ähnliche Artikel