Headless Browser Proxy Auth er ikke en VPN-rute

En VPN kan føre en browsers trafik til en proxyserver og stadig lade browseren være ude af stand til at bruge denne proxy, fordi en rute og en legitimation er forskellige ting. Hovedløs automatisering gør hullet sværere at se, da der ikke er noget vindue og ingen prompt at bemærke. Fejlen optræder normalt som et hængende eller en generisk navigationsfejl, og det første instinkt er at give tunnelen skylden. Tjeklisten nedenfor adskiller de fire ting, der skal være sande, før en hovedløs anmodning via en autentificeret proxy kan lykkes.

To samtaler, to legitimationsoplysninger

Der sker to samtaler, og de tilhører forskellige parter. Browseren opretter først forbindelse til proxy-lytteren, hvilket kan udfordre den for legitimationsoplysninger; proxyen foretager eller tillader derefter den videre forbindelse til destinationen. En VPN kan bære det første ben uden at være det endepunkt, der udfordrer browseren, og det har intet at sige om det andet.

HTTP 407 er signalet, som klienten skal autentificere for proxy-anmodningen, båret i Proxy-Authenticate med svaret forventet i Proxy-Authorization. Det er ikke destinationswebstedets login, og at blande de to er den mest almindelige kilde til forvirring her.

Så de fire kontroller er: hvilken proxy browseren faktisk har valgt, hvem svarer på 407, hvilket netværk browserprocessen er på, og hvordan legitimationsoplysningerne leveres uden et menneske. Hver enkelt kan fejle uafhængigt, og hver fejl ligner hinanden udefra. Arbejd dem i rækkefølge, fordi en senere kontrol ikke kan kompensere for en tidligere. En proxy, der aldrig blev valgt, kan ikke godkendes, og en legitimationsoplysninger, der kun findes på din bærbare computer, kan ikke nå en container.

Tjek 1: hvilken proxy der faktisk er valgt

Start med valg, fordi en browser, der ignorerer din proxy-indstilling, aldrig når udfordringen overhovedet. I Chrome er flaget --proxy-server=proxy.example:3128 , med --proxy-bypass-list for ekskluderinger, og Selenium afslører det samme gennem sine browserindstillinger. En PAC-fil er en anden mekanisme med sine egne fejltilstande.

Bekræft derefter inde fra den kørende browsers miljø i stedet for fra din shell. En uafhængig sonde med samme proxy er curl -x http://proxy.example:3128 -v https://example.com , og dens detaljerede output viser, om CONNECT lykkedes, hvad Proxy-Authenticate kom tilbage, og om en 407 blev returneret. Hvis curl får en 407, og browseren hænger, er legitimationsstien problemet snarere end netværket. Hvis curl lykkes, og browseren ikke gør det, bruger browseren ikke den proxy, du tror, den er.

Tjek 2: hvem besvarer 407

En 407 har en ejer, og navngivningen afgør, hvor rettelsen skal hen. Hvis udfordringen kommer fra virksomhedens proxy, er rettelsen en legitimationsoplysninger, som browseren kan præsentere uden opsyn. Hvis det kommer fra en upstream proxy, som den første sender videre til, tilhører legitimationsoplysningerne det andet hop, og den første proxy sender muligvis udfordringen uændret. Læs autentificeringsomfanget og værten i Proxy-Authenticate-headeren, fordi de navngiver den boks, der spørger.

Bevar denne sondring, uanset hvad du logger på. En proxy-udfordring, en afvist videreforbindelse, et webstedslogon og en VPN-transporttimeout er fire forskellige fejl med fire forskellige ejere, og en generisk fejlmeddelelse ødelægger den information, du har brug for.

Tjek 3: legitimationsstien

Selve legitimationsoplysningerne er, hvor de fleste uovervågede opsætninger går i stykker. Selenium kan indstille en proxy-vært og -port, men HTTP-proxy-godkendelse er ikke en bærbar del af denne konfiguration, og legitimationsoplysninger i proxy-URL'en er ikke en mekanisme, du kan stole på på tværs af browsere og driverversioner. De understøttede muligheder er dem, som din faktiske stak dokumenterer: en browserudvidelse, der besvarer udfordringen, en lokal videresendelsesproxy, der tilføjer headeren og kun kan nås fra jobbet, eller en proxy, der godkender arbejdsbyrden på anden måde. Vælg en med vilje, og kontroller den i forhold til den nøjagtige browser-, driver- og Selenium-version, du vil køre.

Hold legitimationsoplysningerne væk fra de steder, der lækker den. Kommandolinjer er synlige i proceslister, skærmbilleder ender i testrapporter, browsersporinger og HAR-filer fanger overskrifter, og forpligtet testkonfiguration er for evigt. Brug jobbets hemmelige leveringsmekanisme og dets redaktionsregler, og omfang proxykontoen til de destinationer eller rolle, den har brug for.

Hvis organisationen tilbyder en tilladt direkte VPN-rute i stedet for en obligatorisk proxy, skal du sammenligne de to designs eksplicit. Deaktiver ikke proxyen stille og roligt eller efterlign en anden klients godkendelse for at omgå politikken.

Tjek 4: browserprocessens egen netværkskontekst

Dette er den check, folk springer over. En browser lanceret af en arbejder, en container eller en ekstern Selenium Grid-knude bruger dette miljøs netværk, så din bærbare computers VPN-forbindelse og din shells proxy-variabler beskriver en sti, som browseren aldrig berører.

Registrer fem fakta om det mislykkede job: browserværten, den konfigurerede proxy, den indledende resolversti, den valgte rute og ejeren af godkendelsen. Lav derefter en harmløs autoriseret anmodning fra den nøjagtige kontekst, med normal destinations-TLS-bekræftelse og applikationsgodkendelse tilbage. En hovedløs browser, der starter med succes, beviser hverken proxyadgang eller VPN-dækning, og et skærmbillede af en tom side beviser slet ikke noget. Anmodningen, der returnerer 200 gennem hele kæden, er det eneste bevis, der tæller.

Den færdige arbejdsgang har tre egenskaber, der er værd at tjekke som et sæt. Der er en understøttet rute fra browserværten til proxyen, en eksplicit mellemmandspolitik, der navngiver proxyen og destinationerne, og en legitimationslivscyklus, der ikke afhænger af, at en operatør besvarer en usynlig prompt. Hvis nogen af de tre afhænger af en person, er jobbet ikke uovervåget endnu, hvad end udgangskoden siger. Skriv de fem fakta ned, før den næste person arver pipelinen.