مسیری از SOCKS برای FTPSClient در Commons Net

وقتی یک واسط SOCKS در دسترس است، FTPSClient در Commons Net می‌تواند از رابط پروکسی سوکت به‌ارث‌رسیده استفاده کند. سرور 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 مدیران اعتماد پیش‌فرض JVM را انتخاب می‌کند، نه بررسی گواهی فقط بر پایهٔ تاریخ در Commons Net را. از انبار اعتماد موردنظر و نام میزبان گواهی سرور استفاده کنید.

برای انتقال‌های غیرفعال، پیاده‌سازی فعلی FTPSClient سوکت دادهٔ خود را نیز از طریق پروکسی پیکربندی‌شده می‌سازد و سپس لایهٔ TLS را اضافه می‌کند. پس از ورود، از حالت غیرفعال استفاده کنید و کانال دادهٔ محافظت‌شدهٔ لازم را از طریق API عادی FTPS مذاکره کنید. یک اتصال کنترل موفق آن کار را کامل نمی‌کند؛ اتصال دادهٔ غیرفعال مسیری جداگانه می‌ماند.

کد فرض می‌کند سرویس SOCKS بدون حساب اضافی است. پشتیبانی از احراز هویت برای محیط اجرای Java و استقرار انتخابی نیاز به بررسی جداگانه دارد.

این رابط HTTP CONNECT در FTPHTTPClient نیست. آن همزاد FTP معمولی را از طریق تونل HTTP مدیریت می‌کند؛ تغییر پورت آن FTPS اضافه نمی‌کند. اگر شبکه فقط پروکسی HTTP را مجاز می‌داند، پیاده‌سازی FTPS یا سازگارسازی نگه‌داری‌شده‌ای را انتخاب کنید که CONNECT را هم در مسیر کنترل و هم در مسیر داده پشتیبانی کند.

پیکربندی پروکسی را در طول چرخهٔ عمر کلاینت نگه دارید و پیش از اتصال دوبارهٔ نمونهٔ بازاستفاده‌شده آن را بررسی کنید: قطع اتصال FTPS کارخانه‌های سوکت را بازنشانی می‌کند. بررسی‌های گواهی را با یک trust-all manager جایگزین نکنید تا مسیر موفق به نظر برسد.