เส้นทาง SOCKS สำหรับ FTPSClient ของ Commons Net
ใช้อินเทอร์เฟซ socket proxy ของ Commons Net สำหรับ FTPS โดยคงชื่อโฮสต์ของเซิร์ฟเวอร์ การเชื่อมต่อข้อมูลแบบพาสซีฟ และการตรวจสอบ TLS
เมื่อมีตัวกลาง SOCKS FTPSClient ของ Commons Net สามารถใช้อินเทอร์เฟซ socket proxy ที่สืบทอดมาได้ ให้คงเซิร์ฟเวอร์ FTPS เป็นปลายทางการเชื่อมต่อ:
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);
การทำเช่นนี้เริ่มการเชื่อมต่อ FTPS แบบชัดเจน แอปพลิเคชันยังคงรับผิดชอบการเข้าสู่ระบบ การเจรจาเรื่องการป้องกันข้อมูล การจัดการการถ่ายโอน และการตัดการเชื่อมต่อ การตั้งค่า null trust manager เลือก trust manager เริ่มต้นของ JVM แทนการตรวจสอบใบรับรองตามวันที่เท่านั้นของ Commons Net ใช้ trust store ที่ตั้งใจไว้และชื่อโฮสต์ของใบรับรองเซิร์ฟเวอร์
สำหรับการถ่ายโอนแบบพาสซีฟ การทำงานปัจจุบันของ FTPSClient สร้างซ็อกเก็ตข้อมูลผ่านพร็อกซีที่กำหนดค่าไว้ด้วย แล้วจึงเพิ่มชั้น TLS หลังจากเข้าสู่ระบบ ให้ใช้โหมดพาสซีฟและเจรจาช่องทางข้อมูลที่ได้รับการป้องกันผ่าน FTPS API ปกติ การเชื่อมต่อควบคุมที่สำเร็จไม่ถือว่างานนั้นเสร็จสิ้น การเชื่อมต่อข้อมูลแบบพาสซีฟยังคงเป็นเส้นทางแยกต่างหาก
โค้ดสมมติว่าบริการ SOCKS ไม่มีบัญชีเพิ่มเติม การรองรับการพิสูจน์ตัวตนต้องได้รับการตรวจสอบแยกต่างหากสำหรับ Java runtime และการปรับใช้ที่เลือก
นี่ไม่ใช่อินเทอร์เฟซ HTTP CONNECT ของ FTPHTTPClient พี่น้องนั้นจัดการ FTP ทั่วไปผ่านอุโมงค์ HTTP การเปลี่ยนพอร์ตไม่เพิ่ม FTPS หากเครือข่ายอนุญาตเฉพาะพร็อกซี HTTP ให้เลือกการใช้งาน FTPS หรือการดัดแปลงที่ดูแลรักษาซึ่งรองรับ CONNECT ทั้งบนเส้นทางควบคุมและเส้นทางข้อมูล
เก็บการกำหนดค่าพร็อกซีไว้ตลอดวงจรชีวิตของไคลเอนต์ และตรวจสอบก่อนเชื่อมต่ออินสแตนซ์ที่ใช้ซ้ำอีกครั้ง: การตัดการเชื่อมต่อ FTPS จะรีเซ็ตซ็อกเก็ตแฟกทอรี อย่าแทนที่การตรวจสอบใบรับรองด้วย trust-all manager เพื่อให้เส้นทางดูเหมือนสำเร็จ