Die Headless-Browser-Proxy-Authentifizierung ist keine VPN-Route

Ein VPN kann den Datenverkehr eines Browsers an einen Proxyserver weiterleiten, ohne dass der Browser diesen Proxy verwenden kann, da eine Route und Anmeldeinformationen unterschiedliche Dinge sind. Durch die Headless-Automatisierung ist die Lücke schwerer zu erkennen, da es kein Fenster und keine Aufforderung zum Bemerken gibt. Der Fehler erscheint normalerweise als ein Hängenbleiben oder ein allgemeiner Navigationsfehler, und der erste Instinkt ist, dem Tunnel die Schuld zu geben. Die folgende Checkliste trennt die vier Dinge, die wahr sein müssen, bevor eine Headless-Anfrage über einen authentifizierten Proxy erfolgreich sein kann.

Zwei Gespräche, zwei Referenzen

Es finden zwei Gespräche statt, die verschiedenen Parteien gehören. Der Browser stellt zunächst eine Verbindung zum Proxy-Listener her, der ihn möglicherweise zur Eingabe von Anmeldeinformationen auffordert, Der Proxy stellt dann die Weiterverbindung zum Ziel her oder erlaubt diese. Ein VPN kann den ersten Teil übernehmen, ohne der Endpunkt zu sein, der den Browser herausfordert, und über den zweiten Teil hat es nichts zu sagen.

HTTP 407 ist das Signal, dass sich der Client für die Proxy-Anfrage authentifizieren muss, die in Proxy-Authenticate mit der erwarteten Antwort in Proxy-Authorization übertragen wird. Dabei handelt es sich nicht um den Login der Zielwebsite, und die Vermischung der beiden ist hier die häufigste Ursache für Verwirrung.

Die vier Prüfungen sind also: Welchen Proxy hat der Browser tatsächlich ausgewählt, wer auf die 407 antwortet, in welchem Netzwerk sich der Browserprozess befindet und wie die Anmeldeinformationen ohne einen Menschen übermittelt werden. Jeder Fehler kann unabhängig voneinander scheitern, und jeder Fehler sieht von außen ähnlich aus. Arbeiten Sie sie der Reihe nach ab, denn eine spätere Kontrolle kann eine frühere nicht ersetzen. Ein Proxy, der nie ausgewählt wurde, kann nicht authentifiziert werden und Anmeldeinformationen, die nur auf Ihrem Laptop vorhanden sind, können keinen Container erreichen.

Überprüfen Sie 1: welcher Proxy tatsächlich ausgewählt ist

Beginnen Sie mit der Auswahl, denn ein Browser, der Ihre Proxy-Einstellungen ignoriert, wird die Herausforderung überhaupt nicht meistern. In Chrome lautet die Flagge --proxy-server=proxy.example:3128 , wobei --proxy-bypass-list für Ausschlüsse steht, und Selenium macht dasselbe über seine Browseroptionen verfügbar. Eine PAC-Datei ist ein anderer Mechanismus mit eigenen Fehlermodi.

Bestätigen Sie dann in der Umgebung des laufenden Browsers und nicht in Ihrer Shell. Eine unabhängige Sonde mit demselben Proxy ist curl -x http://proxy.example:3128 -v https://example.com und ihre ausführliche Ausgabe zeigt, ob CONNECT erfolgreich war, was Proxy-Authenticate zurückgegeben hat und ob ein 407 zurückgegeben wurde. Wenn Curl einen 407 erhält und der Browser hängt, ist der Anmeldeinformationspfad das Problem und nicht das Netzwerk. Wenn Curl erfolgreich ist und der Browser nicht, verwendet der Browser nicht den Proxy, den Sie vermuten.

Überprüfen Sie 2: Wer antwortet auf 407

Ein 407 hat einen Besitzer und seine Benennung entscheidet darüber, wohin der Fix geht. Wenn die Herausforderung vom Unternehmens-Proxy ausgeht, handelt es sich bei der Lösung um Anmeldeinformationen, die der Browser unbeaufsichtigt präsentieren kann. Wenn es von einem Upstream-Proxy stammt, an den der erste weiterleitet, gehören die Anmeldeinformationen zu diesem zweiten Hop und der erste Proxy leitet die Herausforderung möglicherweise unverändert weiter. Lesen Sie den Authentifizierungsbereich und den Host im Proxy-Authenticate-Header, da sie die Box benennen, die nachfragt.

Behalten Sie diese Unterscheidung bei allem bei, was Sie protokollieren. Eine Proxy-Herausforderung, eine abgelehnte Weiterleitung, eine Website-Anmeldung und ein VPN-Transport-Timeout sind vier verschiedene Fehler mit vier verschiedenen Eigentümern, und eine allgemeine Fehlermeldung zerstört die benötigten Informationen.

Überprüfen Sie 3: den Anmeldeinformationspfad

Der Berechtigungsnachweis selbst ist der Punkt, an dem die meisten unbeaufsichtigten Setups scheitern. Selenium kann einen Proxy-Host und -Port festlegen, aber die HTTP-Proxy-Authentifizierung ist kein portabler Teil dieser Konfiguration, und Anmeldeinformationen in der Proxy-URL sind kein Mechanismus, auf den Sie sich bei allen Browsern und Treiberversionen verlassen können. Die unterstützten Optionen sind diejenigen, die Ihr tatsächlicher Stack dokumentiert: eine Browser-Erweiterung, die die Herausforderung beantwortet, ein lokaler Weiterleitungs-Proxy, der den Header hinzufügt und nur vom Job aus erreichbar ist, oder ein Proxy, der die Arbeitslast auf andere Weise authentifiziert. Wählen Sie bewusst eine aus und vergleichen Sie sie mit den genauen Browser-, Treiber- und Selenium-Versionen, die Sie ausführen werden.

Halten Sie den Ausweis von den Stellen fern, an denen er verloren geht. Befehlszeilen sind in Prozesslisten sichtbar, Screenshots landen in Testberichten, Browser-Traces und HAR-Dateien erfassen Header und festgeschriebene Testkonfigurationen sind für immer gültig. Nutzen Sie den geheimen Übermittlungsmechanismus des Jobs und seine Schwärzungsregeln und richten Sie den Proxy-Account auf die benötigten Ziele oder Rollen aus.

Wenn die Organisation anstelle eines obligatorischen Proxys eine erlaubte direkte VPN-Route anbietet, vergleichen Sie die beiden Designs explizit. Deaktivieren Sie den Proxy nicht stillschweigend und imitieren Sie nicht die Authentifizierung eines anderen Clients, um die Richtlinie zu umgehen.

Überprüfen Sie 4: den eigenen Netzwerkkontext des Browserprozesses

Dies ist der Scheck, den die Leute überspringen. Ein von einem Worker, einem Container oder einem Remote-Selenium-Grid-Knoten gestarteter Browser nutzt das Netzwerk dieser Umgebung, sodass die VPN-Verbindung Ihres Laptops und die Proxy-Variablen Ihrer Shell einen Pfad beschreiben, den der Browser möglicherweise niemals berührt.

Notieren Sie fünf Fakten für den fehlgeschlagenen Job: den Browser-Host, den konfigurierten Proxy, den anfänglichen Resolver-Pfad, die ausgewählte Route und den Besitzer der Authentifizierung. Stellen Sie dann eine harmlose autorisierte Anfrage aus genau diesem Kontext, wobei die normale TLS-Überprüfung des Ziels und die Anwendungsautorisierung aktiviert bleiben. Ein erfolgreich gestarteter Headless-Browser beweist weder Proxy-Zulassung noch VPN-Abdeckung, und ein Screenshot einer leeren Seite beweist überhaupt nichts. Die Anforderung, die über die gesamte Kette 200 zurückgibt, ist der einzige Beweis, der zählt.

Der fertige Workflow verfügt über drei Eigenschaften, die es wert sind, als Gruppe überprüft zu werden. Es gibt eine unterstützte Route vom Browser-Host zum Proxy, eine explizite Vermittlerrichtlinie, die den Proxy und die Ziele benennt, und einen Lebenszyklus der Anmeldeinformationen, der nicht davon abhängt, dass ein Operator auf eine unsichtbare Eingabeaufforderung antwortet. Wenn einer der drei Punkte von einer Person abhängt, ist der Job noch nicht unbeaufsichtigt, unabhängig davon, was im Exit-Code steht. Schreiben Sie die fünf Fakten auf, bevor die nächste Person die Pipeline erbt.