Bezhlavé ověření proxy prohlížeče není cesta VPN

Síť VPN může přenášet provoz prohlížeče na proxy server a přesto prohlížeč nemůže tento proxy server používat, protože trasa a pověření jsou různé věci. Bezhlavá automatizace činí mezeru hůře viditelnou, protože zde není žádné okno ani výzva k upozornění. Selhání se obvykle projeví jako zablokování nebo obecná chyba navigace a prvním instinktem je vinit tunel. Níže uvedený kontrolní seznam odděluje čtyři věci, které musí být pravdivé, než může bezhlavý požadavek prostřednictvím ověřeného proxy uspět.

Dva rozhovory, dvě pověření

Proběhnou dva rozhovory, které patří různým stranám. Prohlížeč se nejprve připojí k proxy listeneru, který jej může vyzvat k získání přihlašovacích údajů; proxy pak vytvoří nebo povolí další připojení k cíli. VPN může nést první úsek, aniž by byla koncovým bodem, který zpochybňuje prohlížeč, a nemá co říci o druhém.

HTTP 407 je signál, že se klient musí ověřit pro požadavek proxy přenášený v Proxy-Authenticate s odpovědí očekávanou v Proxy-Authorization. Nejedná se o přihlašovací údaje cílového webu a jejich smíchání je zde nejčastějším zdrojem zmatků.

Takže čtyři kontroly jsou: který proxy prohlížeč skutečně vybral, kdo odpovídá na 407, na které síti je proces prohlížeče a jak jsou přihlašovací údaje doručeny bez člověka. Každá může selhat nezávisle a každá porucha vypadá zvenčí podobně. Zpracujte je v pořadí, protože pozdější kontrola nemůže kompenzovat dřívější kontrolu. Proxy, který nebyl nikdy vybrán, nelze ověřit a pověření, které existuje pouze na vašem notebooku, nemůže dosáhnout kontejneru.

Zkontrolujte 1: který proxy je skutečně vybrán

Začněte výběrem, protože prohlížeč, který ignoruje vaše nastavení proxy, nikdy nedosáhne výzvy. V Chrome je příznak --proxy-server=proxy.example:3128 , se --proxy-bypass-list pro výjimky a Selenium odhaluje totéž prostřednictvím možností prohlížeče. Soubor PAC je jiný mechanismus s vlastními režimy selhání.

Poté potvrďte z prostředí běžícího prohlížeče, nikoli z vašeho shellu. Nezávislá sonda se stejnou proxy je curl -x http://proxy.example:3128 -v https://example.com a její podrobný výstup ukazuje, zda bylo CONNECT úspěšné, jaké Proxy-Authenticate se vrátilo a zda bylo vráceno 407. Pokud curl dostane 407 a prohlížeč se zablokuje, problém je spíše v cestě pověření než v síti. Pokud curl uspěje a prohlížeč ne, prohlížeč nepoužívá proxy, o které si myslíte, že je.

Zkontrolujte 2: kdo odpovídá na 407

407 má vlastníka a jeho pojmenování rozhoduje o tom, kam se oprava dostane. Pokud výzva pochází z podnikového proxy, oprava je pověření, které může prohlížeč předložit bez dozoru. Pokud pochází z upstream proxy, na kterou první přesměruje, pověření patří tomuto druhému skoku a první proxy může předávat výzvu beze změny. Přečtěte si rozsah autentizace a hostitele v záhlaví Proxy-Authenticate, protože pojmenovávají pole, které se ptá.

Zachovejte tento rozdíl ve všem, co přihlásíte. Výzva serveru proxy, odmítnuté další připojení, přihlášení k webu a časový limit přenosu VPN jsou čtyři různá selhání se čtyřmi různými vlastníky a jedna obecná chybová zpráva zničí informace, které potřebujete.

Zkontrolujte 3: cesta pověření

Samotné pověření je místo, kde se většina bezobslužných nastavení poruší. Selenium může nastavit hostitele a port proxy, ale ověřování HTTP proxy není přenosnou součástí této konfigurace a přihlašovací údaje v URL proxy nejsou mechanismem, na který se můžete spolehnout v různých prohlížečích a verzích ovladačů. Podporované možnosti jsou ty, které jsou součástí vašich skutečných zásobníků dokumentů: rozšíření prohlížeče, které odpovídá na výzvu, místní server proxy pro předávání, který přidává záhlaví a je dosažitelný pouze z úlohy, nebo server proxy, který ověřuje zátěž jinými prostředky. Vyberte si jeden záměrně a porovnejte jej s přesnou verzí prohlížeče, ovladače a Selenium, které budete spouštět.

Uchovávejte pověření mimo místa, kde dochází k jeho úniku. Příkazové řádky jsou viditelné ve výpisech procesů, snímky obrazovky končí v testovacích zprávách, trasování prohlížeče a soubory HAR zachycují záhlaví a konfigurace potvrzeného testu je navždy. Použijte mechanismus tajného doručování úlohy a její pravidla pro redigování a nastavte proxy účet na místa určení nebo roli, kterou potřebuje.

Pokud organizace nabízí povolenou přímou cestu VPN namísto povinného proxy, porovnejte tyto dva návrhy explicitně. Nevypínejte potichu proxy ani nenapodobujte ověřování jiného klienta, abyste obešli zásady.

Zkontrolujte 4: vlastní síťový kontext procesu prohlížeče

Toto je kontrola, kterou lidé přeskakují. Prohlížeč spuštěný pracovníkem, kontejnerem nebo vzdáleným uzlem Selenium Grid využívá síť tohoto prostředí, takže připojení VPN vašeho notebooku a proxy proměnné vašeho shellu popisují cestu, které se prohlížeč nikdy nedotkne.

Zaznamenejte pět faktů o neúspěšné úloze: hostitele prohlížeče, nakonfigurovaný proxy server, počáteční cestu překladače, vybranou cestu a vlastníka ověřování. Poté proveďte jeden neškodný autorizovaný požadavek přesně z tohoto kontextu s běžným ověřením cílového TLS a autorizací aplikace. Bezhlavý prohlížeč, který se úspěšně spustí, neprokazuje ani příjem proxy, ani pokrytí VPN a snímek obrazovky prázdné stránky nedokazuje vůbec nic. Požadavek, který vrací 200 v celém řetězci, je jediným důkazem, který se počítá.

Hotový pracovní postup má tři vlastnosti, které stojí za to zkontrolovat jako sadu. Existuje podporovaná cesta z hostitele prohlížeče k proxy, explicitní zprostředkovatelská politika, která pojmenovává proxy a cíle, a životní cyklus pověření, který nezávisí na operátorovi, který odpovídá na neviditelnou výzvu. Pokud některá z těchto tří závisí na osobě, práce ještě není bezobslužná, ať už výstupní kód říká cokoli. Zapište si pět faktů, než další osoba zdědí potrubí.