En SOCKS-rutt för Commons Nets FTPSClient

När en SOCKS-mellanhand finns tillgänglig kan Commons Nets FTPSClient använda det ärvda socket-proxy-gränssnittet. Behåll FTPS-servern som anslutningens 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);

Detta startar en explicit FTPS-anslutning. Programmet ansvarar fortfarande för inloggning, förhandling om dataskydd, hantering av överföringen och frånkoppling. Inställningen null trust manager väljer JVM:ns standard trust managers i stället för Commons Nets datum-baserade certifikatkontroll. Använd det avsedda trust store och serverns certifikat-värdnamn.

Vid passiva överföringar skapar den nuvarande FTPSClient-implementeringen även sin datasocket via den konfigurerade proxyn och lägger sedan till TLS-lagret. Efter inloggning, använd passivt läge och förhandla den nödvändiga skyddade datakanalen via det vanliga FTPS-API:et. En lyckad kontrollanslutning slutför inte det arbetet; den passiva dataanslutningen förblir en separat väg.

Koden förutsätter en SOCKS-tjänst utan ett extra konto. Stöd för autentisering kräver separat granskning för den valda Java-körmiljön och driftsättningen.

Detta är inte HTTP CONNECT-gränssnittet i FTPHTTPClient. Den syskonen hanterar vanlig FTP över en HTTP-tunnel; att ändra dess port lägger inte till FTPS. Om nätverket bara tillåter en HTTP-proxy, välj en FTPS-implementering eller en underhållen anpassning som stöder CONNECT på både kontroll- och datavägen.

Behåll proxykonfigurationen under hela klientens livscykel och granska den innan en återanvänd instans ansluts igen: frånkoppling av FTPS återställer socketfabrikerna. Byt inte ut certifikatkontroller mot en trust-all-manager för att få rutten att verka lyckad.