وہ 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 موڈ درکار ہوتا ہے۔ کنٹرول چینل پر کامیاب لاگ اِن اس راستے کا آغاز ہے، یہ ثبوت نہیں کہ ہر ڈیٹا منتقلی پہلے ہی اجازت یافتہ ہے۔