A proxyn keresztüli Mechanize HTTPS-kérés mögötti rétegek

Nézze meg, hogyan működik együtt a Mechanize, az LWP HTTPS-protokollmodulja és az SSL-háttér egy HTTPS-kérés útvonalválasztásában, alagutazásában és ellenőrzésében.

Állítsa be az útvonalat a Mechanize objektumon a lekérés előtt:

use WWW::Mechanize;

my $mech = WWW::Mechanize->new(timeout => 30);
$mech->proxy(
    ['http', 'https'],
    'http://proxy.example.net:8080',
);

Használja a példában szereplő szándékolt HTTP-figyelőt; az engedélyezett nyilvános célok felé irányuló kéréseknél a jelöltek a HTTP proxy listán találhatók. A tömb a cél-sémákat nevezi meg. A http:// végpont hagyományos CONNECT-útvonalat biztosít a HTTPS-hez: HTTP a proxyhoz, alagút a célhoz, majd a cél TLS-e. Ha a telepítés helyette környezeti beállításokat használ, a $mech->env_proxy az alternatíva; ezek utólagos importálása megváltoztathatja a kódban hozzárendelt útvonalat.

A Mechanize a LWP::UserAgent hálózatkezelését örökli, ahelyett hogy külön HTTPS-proxy motort biztosítana:

  • A Mechanize hivatkozásokat, űrlapokat és az aktuális oldal viselkedését biztosítja.
  • Az LWP::UserAgent és HTTP-szállítása kiválasztja az útvonalat és megszervezi a CONNECT-et.
  • Az LWP::Protocol::https biztosítja a HTTPS kezelését és frissíti a kapcsolatot.
  • A Net::HTTPS az SSL-háttérrel biztosítja a TLS-képes socketet, modern konfigurációkban általában az IO::Socket::SSL-t.

A telepített SSL-háttér önmagában nem választ proxyt. Tartsa meg az eredeti HTTPS-gépnevet az URL-ben: a CONNECT elfogadása nem ellenőrzi az adott webhely tanúsítványát.

Régi összetevők karbantartásakor különböztesse meg ezeket a határokat. A libwww-perl 6.06 és a külön terjesztett LWP::Protocol::https 6.06 összehangolt javításokat vezetett be a normál HTTP CONNECT-hez. A UserAgent verziója önmagában nem azonosítja a HTTPS-modult. Az LWP::Protocol::https 6.15 javítást adott a TLS-t engedélyező proxy végpontokhoz, amelyek https:// sémája a cél TLS-e előtt TLS-t ad a proxyhoz.

A régebbi Net::SSL/Crypt::SSLeay-konfigurációk helyette használhatják az adott háttér dokumentált HTTPS_PROXY környezeti mechanizmusát. Ne alkalmazza annak receptjét a modern IO::Socket::SSL-útvonalra, ahol az LWP felel az útvonalválasztásért.

Az első sikertelen szakasz alapján válassza ki az összetevőt: a hiányzó HTTPS-kezelő a protokollmodult érinti; az elutasított CONNECT az útvonalat, a hitelesítő adatokat vagy a szabályzatot érinti; az alagút utáni tanúsítványhiba a cél azonosságát és bizalmát érinti. Őrizze meg az ellenőrzést, miközben az adott bizonyíték által támogatott összetevőt cseréli.

Kapcsolódó cikkek