SOCKS-itinero por FTPSClient de Commons Net

Kiam disponeblas SOCKS-peranto, la FTPSClient de Commons Net povas uzi la hereditan soket-prokuran interfacon. Konservu la FTPS-servilon kiel celon de la konekto:

var client = new org.apache.commons.net.ftp.FTPSClient(false);
client.setProxy(new java.net.Proxy(
    java.net.Proxy.Type.SOCKS,
    new java.net.InetSocketAddress("proxy.example", 1080)));
client.setTrustManager(null);
client.setEndpointCheckingEnabled(true);
client.setConnectTimeout(10000);
client.connect("ftps.example", 21);

Ĉi tio komencas eksplicitan FTPS-konekton. La aplikaĵo plu respondecas pri ensaluto, negocado de datuma protekto, administrado de translokigo kaj malkonekto. La agordo de nula trust manager elektas la defaŭltajn trust manager-ojn de la JVM anstataŭ la dat-bazita atestila kontrolo de Commons Net. Uzu la celitan trust store kaj la atestilan gastigan nomon de la servilo.

Por pasivaj translokigoj, la nuna FTPSClient-realigo kreas sian datuman soketon ankaŭ tra la agordita prokuro, poste aldonas la TLS-tavolon. Post ensaluto, uzu pasivan reĝimon kaj negocu la bezonatan protektitan datuman kanalon per la normala FTPS-API. Sukcesa regada konekto ne plenumos tiun laboron; la pasiva datuma konekto restas aparta vojo.

La kodo supozas SOCKS-servon sen aldona konto. Subteno de aŭtentikigo bezonas apartan revizion por la elektita Java-rultempo kaj deplojo.

Ĉi tio ne estas la HTTP CONNECT-interfaco de FTPHTTPClient. Tiu frato traktas ordinarajn FTP per HTTP-tunelo; ŝanĝi ĝian pordon ne aldonas FTPS. Se la reto permesas nur HTTP-prokuron, elektu FTPS-realigon aŭ prizorgatan adaptaĵon, kiu subtenas CONNECT kaj sur la regada kaj sur la datuma vojo.

Konservu la prokuran agordon dum la tuta vivociklo de la kliento, kaj reviziu ĝin antaŭ rekonekti reuzatan ekzempleron: FTPS-malkonekto restarigas soketfabrikojn. Ne anstataŭigu atestilkontrolojn per trust-all manager por ŝajnigi la itinieron sukcesa.