तुमचा गेटवे अपेक्षित 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 मोड लागतो. नियंत्रण चॅनेलवरील यशस्वी लॉगिन त्या मार्गाची सुरुवात आहे, प्रत्येक डेटा हस्तांतरण आधीच अनुमत आहे याचा पुरावा नाही.