En SOCKS-rute til Commons Nets FTPSClient

Når en SOCKS-mellemmand er tilgængelig, kan Commons Nets FTPSClient bruge den nedarvede socket-proxy-grænseflade. Behold FTPS-serveren som forbindelsens destination:

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);

Dette starter en eksplicit FTPS-forbindelse. Programmet ejer stadig login, forhandling om databeskyttelse, håndtering af overførsel og afbrydelse. Indstillingen null trust manager vælger JVM’ens standard-trust-managere i stedet for Commons Nets datobaserede certifikatkontrol. Brug det tilsigtede trust store og serverens certifikat-værtsnavn.

Ved passive overførsler opretter den nuværende FTPSClient-implementering også sin datassocket gennem den konfigurerede proxy og tilføjer derefter TLS-laget. Efter login skal du bruge passiv tilstand og forhandle den krævede beskyttede datakanal via det normale FTPS-API. En vellykket kontrolforbindelse fuldfører ikke det arbejde; den passive dataforbindelse forbliver en separat vej.

Koden forudsætter en SOCKS-tjeneste uden en ekstra konto. Understøttelse af godkendelse kræver særskilt gennemgang for det valgte Java-runtime og den valgte udrulning.

Dette er ikke FTPHTTPClients HTTP CONNECT-grænseflade. Den søster håndterer almindelig FTP over en HTTP-tunnel; at ændre dens port tilføjer ikke FTPS. Hvis netværket kun tillader en HTTP-proxy, skal du vælge en FTPS-implementering eller vedligeholdt tilpasning, der understøtter CONNECT på både kontrol- og datastien.

Behold proxy-konfigurationen gennem klientens livscyklus, og gennemgå den, før en genbrugt instans tilsluttes igen: afbrydelse af FTPS nulstiller socket-fabrikker. Erstat ikke certifikatkontroller med en trust-all-manager for at få ruten til at se vellykket ud.