Headless Browser Proxy Auth is geen VPN-route

Een VPN kan het verkeer van een browser naar een proxyserver transporteren en de browser toch niet in staat stellen die proxy te gebruiken, omdat een route en een inloggegevens verschillende dingen zijn. Headless-automatisering maakt de kloof moeilijker te zien, omdat er geen venster is en geen prompt om op te merken. De storing manifesteert zich meestal als een vastgelopen of algemene navigatiefout, en het eerste instinct is om de tunnel de schuld te geven. De onderstaande checklist scheidt de vier dingen die waar moeten zijn voordat een headless verzoek via een geverifieerde proxy kan slagen.

Twee gesprekken, twee referenties

Er vinden twee gesprekken plaats, en deze zijn van verschillende partijen. De browser maakt eerst verbinding met de proxy-listener, die mogelijk om inloggegevens vraagt; de proxy maakt of staat vervolgens de verdere verbinding met de bestemming toe. Een VPN kan het eerste deel uitvoeren zonder het eindpunt te zijn dat de browser uitdaagt, en het heeft niets te zeggen over het tweede deel.

HTTP 407 is het signaal dat de client moet verifiëren voor het proxyverzoek, opgenomen in Proxy-Authenticate met het verwachte antwoord in Proxy-Authorization. Dat is niet de login van de bestemmingswebsite, en het combineren van deze twee is hier de meest voorkomende bron van verwarring.

De vier controles zijn dus: welke proxy de browser daadwerkelijk heeft geselecteerd, wie de 407 beantwoordt, op welk netwerk het browserproces zich bevindt en hoe de inloggegevens worden afgeleverd zonder dat er een mens aanwezig is. Ze kunnen allemaal afzonderlijk falen, en elke mislukking ziet er van buitenaf hetzelfde uit. Werk ze op volgorde af, want een latere controle kan een eerdere controle niet compenseren. Een proxy die nooit is geselecteerd, kan niet worden geverifieerd en een inloggegevens die alleen op uw laptop staan, kunnen een container niet bereiken.

Controleer 1: welke proxy daadwerkelijk is geselecteerd

Begin met selectie, want een browser die uw proxy-instelling negeert, bereikt de uitdaging helemaal niet. In Chrome is de vlag --proxy-server=proxy.example:3128 , met --proxy-bypass-list voor uitsluitingen, en Selenium laat hetzelfde zien via zijn browseropties. Een PAC-bestand is een ander mechanisme met zijn eigen faalmodi.

Bevestig vervolgens vanuit de actieve browseromgeving in plaats van vanuit uw shell. Een onafhankelijke test met dezelfde proxy is curl -x http://proxy.example:3128 -v https://example.com , en de uitgebreide uitvoer laat zien of de CONNECT is geslaagd, wat Proxy-Authenticate terugkwam en of een 407 werd geretourneerd. Als curl een 407 krijgt en de browser blijft hangen, is het pad van de inloggegevens het probleem en niet het netwerk. Als curl slaagt en de browser niet, gebruikt de browser niet de proxy die u denkt dat deze is.

Controleer 2: wie antwoordt op de 407

Een 407 heeft een eigenaar, en de naamgeving ervan bepaalt waar de oplossing naartoe gaat. Als de uitdaging afkomstig is van de bedrijfsproxy, is de oplossing een inloggegevens die de browser onbeheerd kan presenteren. Als het afkomstig is van een upstream-proxy waar de eerste naar doorstuurt, behoort de referentie tot die tweede hop en geeft de eerste proxy de uitdaging mogelijk ongewijzigd door. Lees het authenticatiebereik en de host in de Proxy-Authenticate-header, omdat ze de box een naam geven die vraagt.

Behoud dat onderscheid in wat u ook logt. Een proxy-uitdaging, een geweigerde verdere verbinding, een website-aanmelding en een VPN-transporttime-out zijn vier verschillende fouten met vier verschillende eigenaren, en één algemeen foutbericht vernietigt de informatie die u nodig heeft.

Controleer 3: het referentiepad

De referentie zelf is waar de meeste onbeheerde opstellingen kapot gaan. Selenium kan een proxyhost en -poort instellen, maar HTTP-proxyverificatie is geen overdraagbaar onderdeel van die configuratie, en inloggegevens in de proxy-URL zijn geen mechanisme waarop u kunt vertrouwen in verschillende browsers en stuurprogrammaversies. De ondersteunde opties zijn de opties die uw werkelijke stapeldocumenten zijn: een browserextensie die de uitdaging beantwoordt, een lokale doorstuurproxy die de header toevoegt en alleen bereikbaar is vanuit de taak, of een proxy die de werklast op andere manieren verifieert. Kies er bewust een en vergelijk deze met de exacte browser-, driver- en Selenium-versies die u gaat gebruiken.

Houd de identificatie uit de plaatsen waar deze lekt. Commandoregels zijn zichtbaar in procesoverzichten, schermafbeeldingen komen terecht in testrapporten, browsersporen en HAR-bestanden leggen headers vast, en toegewijde testconfiguratie is voor altijd. Gebruik het geheime leveringsmechanisme van de taak en de bijbehorende redactieregels, en bereik het proxy-account op de bestemmingen of rol die het nodig heeft.

Als de organisatie een toegestane directe VPN-route aanbiedt in plaats van een verplichte proxy, vergelijk de twee ontwerpen dan expliciet. Schakel de proxy niet stilletjes uit en imiteer de authenticatie van een andere client niet om het beleid te omzeilen.

Controleer 4: de eigen netwerkcontext van het browserproces

Dit is de cheque die mensen overslaan. Een browser die wordt gestart door een medewerker, een container of een extern Selenium Grid-knooppunt maakt gebruik van de netwerken van die omgeving, dus de VPN-verbinding van uw laptop en de proxyvariabelen van uw shell beschrijven een pad dat de browser mogelijk nooit zal aanraken.

Noteer vijf feiten voor de falende taak: de browserhost, de geconfigureerde proxy, het initiële oplosserpad, de geselecteerde route en de eigenaar van de authenticatie. Voer vervolgens één onschadelijk geautoriseerd verzoek uit vanuit die exacte context, waarbij de normale bestemming-TLS-verificatie en applicatie-autorisatie ingeschakeld blijven. Een headless browser die succesvol opstart, bewijst noch proxy-toegang, noch VPN-dekking, en een screenshot van een lege pagina bewijst helemaal niets. Het verzoek dat 200 door de hele keten retourneert, is het enige bewijs dat telt.

De voltooide workflow heeft drie eigenschappen die de moeite waard zijn om als set te controleren. Er is een ondersteunde route van de browserhost naar de proxy, een expliciet tussenbeleid dat de proxy en de bestemmingen een naam geeft, en een levenscyclus van inloggegevens die niet afhankelijk is van een operator die een onzichtbare vraag beantwoordt. Als een van de drie afhankelijk is van een persoon, is de taak nog niet onbeheerd, wat de exitcode ook zegt. Schrijf de vijf feiten op voordat de volgende persoon de pijpleiding erft.