SOCKS მარშრუტი Commons Net-ის FTPSClient-ისთვის

როცა SOCKS შუამავალი ხელმისაწვდომია, Commons Net-ის FTPSClient-ს შეუძლია მემკვიდრეობით მიღებული 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 პარამეტრი ირჩევს JVM-ის ნაგულისხმევ trust manager-ებს და არა Commons Net-ის მხოლოდ თარიღზე დაფუძნებულ სერტიფიკატის შემოწმებას. გამოიყენეთ განკუთვნილი trust store და სერვერის სერტიფიკატის ჰოსტის სახელი.

პასიური გადაცემებისთვის FTPSClient-ის მიმდინარე იმპლემენტაცია თავის მონაცემთა socket-საც კონფიგურირებული პროქსის მეშვეობით ქმნის, შემდეგ ამატებს TLS შრეს. შესვლის შემდეგ გამოიყენეთ პასიური რეჟიმი და ჩვეულებრივი FTPS API-ის მეშვეობით შეათანხმეთ საჭირო დაცული მონაცემთა არხი. წარმატებული მართვის კავშირი ამ სამუშაოს არ ასრულებს; პასიური მონაცემთა კავშირი ცალკე გზად რჩება.

კოდი ვარაუდობს SOCKS სერვისს დამატებითი ანგარიშის გარეშე. აუტენტიფიკაციის მხარდაჭერა ცალკე განხილვას მოითხოვს არჩეული Java გარემოსა და განთავსებისთვის.

ეს არ არის FTPHTTPClient-ის HTTP CONNECT ინტერფეისი. ის ძმა ჩვეულებრივ FTP-ს HTTP გვირაბის მეშვეობით ამუშავებს; მისი პორტის შეცვლა FTPS-ს არ ამატებს. თუ ქსელი მხოლოდ HTTP პროქსის უშვებს, აირჩიეთ FTPS იმპლემენტაცია ან შენარჩუნებული ადაპტაცია, რომელიც CONNECT-ს მართვისა და მონაცემთა ორივე გზაზე უჭერს მხარს.

შეინარჩუნეთ პროქსის კონფიგურაცია კლიენტის სიცოცხლის ციკლის განმავლობაში და გადახედეთ მას ხელახლა გამოყენებული ინსტანციის ხელახლა დაკავშირებამდე: FTPS-ის გაწყვეტა socket ქარხნებს არესეტებს. არ შეცვალოთ სერტიფიკატის შემოწმებები trust-all manager-ით, რომ მარშრუტი წარმატებულად გამოიყურებოდეს.