अपने गेटवे की अपेक्षित FTP प्रॉक्सी लॉगिन विधि चुनें
किसी मूल FTP गेटवे की USER, SITE या OPEN बातचीत को उसका समर्थन करने वाले क्लाइंट से मिलाएँ, गेटवे खाते को लक्ष्य खाते से अलग रखते हुए।
“FTP प्रॉक्सी” ऐसे गेटवे को दर्शा सकता है जो स्वयं FTP बोलता है। उससे जुड़ना HTTP प्रॉक्सी से CONNECT माँगने या SOCKS सर्वर से TCP गंतव्य खोलने को कहने से भिन्न है।
गेटवे को लक्ष्य होस्ट और खाता चाहिए, और पहले उसे अपना लॉगिन भी चाहिए हो सकता है। उत्पाद उस बातचीत को अलग-अलग तरीक़ों से व्यक्त करते हैं:
| व्यवस्था | सामान्य आदेश का रूप |
|---|---|
| उपयोगकर्ता नाम में लक्ष्य एन्कोडेड | USER target-user@target-host |
| अलग गेटवे लॉगिन | गेटवे USER/PASS, फिर लक्ष्य का लॉगिन |
| स्पष्ट गंतव्य आदेश | SITE target-host या OPEN target-host, फिर आवश्यक लॉगिन |
ये परिपाटियों के परिवार हैं, हर गेटवे को भेजने का कोई एक मानक क्रम नहीं। वह विधि चुनें जो प्रशासक ने प्रलेखित की है और क्लाइंट समर्थन करता है।
सेटअप में दोनों खाते दृश्य रखें
लक्ष्य का FTP पासवर्ड और गेटवे का पासवर्ड भिन्न हो सकते हैं। कुछ गेटवे उन्हें एक USER/PASS निरूपण में जोड़ देते हैं; अन्य अलग आदान-प्रदान चाहते हैं। हर मान को एक स्ट्रिंग में रखकर उस क्लाइंट का पुनरुत्पादन नहीं हो सकता जिसे अतिरिक्त आदेश भेजने पड़ते हैं।
यह पुराने FtpWebRequest कोड में एक उपयोगी सीमा समझाता है। गेटवे से सामान्य FTP कनेक्शन, गेटवे-विशिष्ट उपयोगकर्ता नाम के साथ, कुछ USER/PASS व्यवस्थाओं में फ़िट हो सकता है। अलग SITE या OPEN बातचीत माँगने वाले गेटवे को ऐसा क्लाइंट चाहिए जो वास्तव में उस प्रवाह का समर्थन करे। WebRequest का Proxy गुण फिर एक और इंटरफ़ेस है।
उदाहरण के लिए WinSCP सभी गेटवे को एक होस्ट फ़ील्ड मानने के बजाय अलग FTP प्रॉक्सी लॉगिन विधियाँ प्रदान करता है। उसके संख्यात्मक कच्चे सेटिंग मान उसके प्रलेखित API के हैं; कॉन्फ़िगरेशन की समीक्षा करते समय विधि का नाम और इच्छित बातचीत उपयोग करें।
लॉगिन के बाद भी फ़ाइल स्थानांतरण को FTP डेटा कनेक्शन और चुना गया TLS मोड चाहिए। नियंत्रण चैनल पर सफल लॉगिन उस मार्ग की शुरुआत है, यह प्रमाण नहीं कि हर डेटा स्थानांतरण पहले से अनुमत है।