כאשר מתווך 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. אל תחליפו בדיקות תעודה במנהל אמון מלא כדי שהנתיב ייראה מוצלח.

מאמרים קשורים