Headless Browser Proxy Auth är inte en VPN-rutt

En VPN kan föra en webbläsares trafik till en proxyserver och fortfarande lämna webbläsaren oförmögen att använda den proxyn, eftersom en rutt och en referens är olika saker. Huvudlös automatisering gör gapet svårare att se, eftersom det inte finns något fönster och ingen uppmaning att lägga märke till. Felet uppträder vanligtvis som ett häng eller ett generiskt navigeringsfel, och den första instinkten är att skylla på tunneln. Checklistan nedan separerar de fyra saker som måste vara sanna innan en huvudlös begäran via en autentiserad proxy kan lyckas.

Två samtal, två referenser

Två samtal sker, och de tillhör olika parter. Webbläsaren ansluter först till proxyavlyssnaren, vilket kan utmana den för autentiseringsuppgifter; proxyn gör eller tillåter den vidare anslutningen till destinationen. En VPN kan bära det första benet utan att vara slutpunkten som utmanar webbläsaren, och det har inget att säga om det andra.

HTTP 407 är signalen som klienten måste autentisera för proxybegäran, bärs i Proxy-Authenticate med svaret förväntat i Proxy-Authorization. Det är inte destinationswebbplatsens inloggning, och att blanda de två är den vanligaste källan till förvirring här.

Så de fyra kontrollerna är: vilken proxy som webbläsaren faktiskt valde, vem som svarar på 407, vilket nätverk webbläsarprocessen är på och hur referensen levereras utan en människa. Var och en kan misslyckas oberoende av varandra, och varje misslyckande ser likadant ut utifrån. Arbeta dem i ordning, eftersom en senare kontroll inte kan kompensera för en tidigare. En proxy som aldrig valdes kan inte autentiseras, och en autentiseringsinformation som bara finns på din bärbara dator kan inte nå en behållare.

Kontrollera 1: vilken proxy som faktiskt är vald

Börja med urval, eftersom en webbläsare som ignorerar din proxyinställning aldrig når utmaningen alls. I Chrome är flaggan --proxy-server=proxy.example:3128 , med --proxy-bypass-list för undantag, och Selenium exponerar samma sak genom sina webbläsaralternativ. En PAC-fil är en annan mekanism med sina egna fellägen.

Bekräfta sedan inifrån den pågående webbläsarens miljö snarare än från ditt skal. En oberoende sond med samma proxy är curl -x http://proxy.example:3128 -v https://example.com , och dess utförliga utdata visar om CONNECT lyckades, vad Proxy-Authenticate kom tillbaka och om en 407 returnerades. Om curl får en 407 och webbläsaren hänger sig, är referenssökvägen problemet snarare än nätverket. Om curl lyckas och webbläsaren inte gör det, använder webbläsaren inte den proxy du tror att den är.

Kontrollera 2: vem svarar på 407

En 407 har en ägare, och namngivningen avgör vart korrigeringen går. Om utmaningen kommer från företagets proxy, är korrigeringen en referens som webbläsaren kan presentera utan uppsikt. Om det kommer från en uppströms proxy som den första vidarebefordrar till, tillhör referensen det andra hoppet och den första proxyn kan vidarebefordra utmaningen oförändrad. Läs autentiseringens omfattning och värd i Proxy-Authenticate-huvudet, eftersom de namnger rutan som frågar.

Bevara den distinktionen i vad du än loggar. En proxyutmaning, en vägrad vidarekoppling, en webbplatsinloggning och en VPN-transport timeout är fyra olika fel med fyra olika ägare, och ett allmänt felmeddelande förstör informationen du behöver.

Kontrollera 3: autentiseringssökvägen

Själva referensen är där de flesta obevakade inställningarna går sönder. Selenium kan ställa in en proxyvärd och port, men HTTP-proxyautentisering är inte en portabel del av den konfigurationen, och autentiseringsuppgifterna i proxy-URL:n är inte en mekanism som du kan lita på i alla webbläsare och drivrutinsversioner. De alternativ som stöds är de som dina faktiska stackdokument: ett webbläsartillägg som svarar på utmaningen, en lokal vidarebefordransproxy som lägger till rubriken och som bara kan nås från jobbet, eller en proxy som autentiserar arbetsbelastningen på annat sätt. Välj en medvetet och kontrollera den mot exakt webbläsare, drivrutin och Selenium-versioner du kommer att köra.

Håll legitimationen borta från de ställen som läcker den. Kommandorader är synliga i processlistor, skärmdumpar hamnar i testrapporter, webbläsarspårningar och HAR-filer fångar rubriker, och beprövad testkonfiguration är för alltid. Använd jobbets hemliga leveransmekanism och dess redigeringsregler, och omfång proxykontot till de destinationer eller roller som det behöver.

Om organisationen erbjuder en tillåten direkt VPN-rutt istället för en obligatorisk proxy, jämför de två designerna uttryckligen. Inaktivera inte proxyn i tysthet eller imitera en annan klients autentisering för att komma runt policyn.

Kontrollera 4: webbläsarprocessens eget nätverkskontext

Det här är kontrollen som folk hoppar över. En webbläsare som startas av en arbetare, en behållare eller en avlägsen Selenium Grid-nod använder den miljöns nätverk, så din bärbara dators VPN-anslutning och ditt skals proxyvariabler beskriver en sökväg som webbläsaren aldrig kommer att röra vid.

Registrera fem fakta för det misslyckade jobbet: webbläsarvärden, den konfigurerade proxyn, den initiala lösningsvägen, den valda rutten och ägaren till autentiseringen. Gör sedan en ofarlig auktoriserad begäran från det exakta sammanhanget, med normal destinations-TLS-verifiering och applikationsauktorisering kvar. En huvudlös webbläsare som startar framgångsrikt bevisar varken proxy-tillträde eller VPN-täckning, och en skärmdump av en tom sida bevisar ingenting alls. Begäran som returnerar 200 genom hela kedjan är det enda beviset som räknas.

Det färdiga arbetsflödet har tre egenskaper som är värda att kontrollera som en uppsättning. Det finns en rutt som stöds från webbläsarvärden till proxyn, en explicit mellanhandspolicy som namnger proxyn och destinationerna, och en autentiseringslivscykel som inte är beroende av att en operatör svarar på en osynlig uppmaning. Om någon av de tre beror på en person är jobbet inte obevakat än, vad än utträdeskoden säger. Skriv ner de fem fakta innan nästa person ärver pipelinen.