נתיב SOCKS ל-FTPSClient של Commons Net
השתמשו בממשק פרוקסי ה-socket של Commons Net עבור FTPS תוך שמירה על שם המארח של השרת, חיבורי נתונים פסיביים ואימות TLS.
כאשר מתווך SOCKS זמין, ה-FTPSClient של Commons Net יכול להשתמש בממשק פרוקסי ה-socket שעבר בירושה. השאירו את שרת ה-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 מפורש. היישום עדיין אחראי להתחברות, למשא ומתן על הגנת נתונים, לטיפול בהעברה ולניתוק. הגדרת trust manager אפס בוחרת את מנהלי האמון המוגדרים כברירת מחדל של ה-JVM במקום בדיקת התעודה לפי תאריך בלבד של Commons Net. השתמשו במאגר האמון המיועד ובשם המארח של תעודת השרת.
בהעברות פסיביות, מימוש ה-FTPSClient הנוכחי יוצר גם את socket הנתונים דרך הפרוקסי המוגדר, ואז מוסיף את שכבת ה-TLS. לאחר ההתחברות, השתמשו במצב פסיבי ונהלו משא ומתן על ערוץ הנתונים המוגן הנדרש דרך ה-API הרגיל של FTPS. חיבור בקרה מוצלח אינו משלים את העבודה הזו; חיבור הנתונים הפסיבי נשאר נתיב נפרד.
הקוד מניח שירות SOCKS ללא חשבון נוסף. תמיכת אימות דורשת סקירה נפרדת עבור סביבת ההרצה של Java והפריסה שנבחרו.
זה אינו ממשק ה-HTTP CONNECT של FTPHTTPClient. האח הזה מטפל ב-FTP רגיל דרך מנהרת HTTP; שינוי הפורט שלו אינו מוסיף FTPS. אם הרשת מאפשרת רק פרוקסי HTTP, בחרו מימוש FTPS או התאמה מתוחזקת שתומכת ב-CONNECT גם בנתיב הבקרה וגם בנתיב הנתונים.
שמרו על תצורת הפרוקסי לאורך כל מחזור החיים של הלקוח, ובדקו אותה לפני חיבור מחדש של מופע שנעשה בו שימוש חוזר: ניתוק FTPS מאפס את מפעלי ה-socket. אל תחליפו בדיקות תעודה במנהל אמון מלא כדי שהנתיב ייראה מוצלח.