B zerbitzarian interaktiboki funtzionatzen duen web-eskaera batek 407 jaso dezake komando bera han PowerShell remoting bidez exekutatzen denean. A-tik B-ra saioa hasten denean, ez da automatikoki delegatzen identitate hori B-ren hurrengo autentifikazio-trukerako.

A → remoting session on B → HTTP proxy → website

Onartutako diseinu bat da proxy-kontua modu esplizituan ematea irteerako eskaerarako. Dagoen PSSession batekin eta behar bezala lortutako PSCredential objektu batekin:

Invoke-Command -Session $session -ArgumentList $proxyCredential -ScriptBlock {
    param([pscredential]$outboundProxyCredential)

    $requestOptions = @{
        Uri = 'https://api.example/'
        Proxy = 'http://proxy.example:8080'
        ProxyCredential = $outboundProxyCredential
    }
    Invoke-WebRequest @requestOptions
}

Kredentzial-objektua proxyaren aurreikusitako kontuarentzat da. Saioak bere remoting autentifikazio arrunta erabiltzen jarraitzen du, eta webgune bateko edozein saio-hasiera webgune horretako eskaeraren parte izaten jarraitzen du.

Horrela, lehen saioaren delegatze automatikoan oinarritzea saihesten da. Hala ere, urruneko ostalariak emandako kontu-materiala aurreikusitako administrazio-diseinuaren parte gisa tratatzea eskatzen du. Beste arkitektura batzuek, hala nola RunAs amaiera-puntu kudeatuak edo zerbitzu-sarbide mugatuak, beren konfigurazio-baldintzak dituzte.

Proxy-kredentzial lehenetsiak suposizio okerra izan baziren, erregistratu urruneko komandoa zein konturen pean exekutatzen den eta proxyak eskatzen duen autentifikazioa. Web-eskaeraren itxaronaldi luzeago batek ezin du falta den kredentzialik eman.

New-PSSessionOption-en proxy-aukerak remoting konexioari berari dagozkio. Konfiguratu Invoke-WebRequest urruneko script blokearen barruan, B-ren kanpoko web-konexioa dena proxyaren beharra duena.

Erlazionatutako artikuluak