اختر طريقة تسجيل الدخول إلى وسيط FTP التي تتوقعها بوابتك
طابِق محادثة USER أو SITE أو OPEN لبوابة FTP أصلية مع عميل يدعمها، مع إبقاء حساب البوابة منفصلاً عن حساب الهدف.
قد يصف “وسيط 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 منفصلة فتحتاج عميلاً يدعم ذلك التدفق فعلاً. وخاصية Proxy في WebRequest واجهة أخرى مرة أخرى.
يعرض WinSCP، على سبيل المثال، طرائق تسجيل دخول منفصلة لوسيط FTP بدلاً من معاملة كل البوابات كحقل مضيف واحد. تنتمي قيم إعداداته الخام الرقمية إلى واجهة API الموثقة لديه؛ استخدم اسم الطريقة والمحادثة المقصودة عند مراجعة إعداد ما.
بعد تسجيل الدخول، لا يزال نقل الملفات يحتاج إلى اتصال بيانات FTP وإلى وضع TLS المختار. تسجيل دخول ناجح على قناة التحكم هو بداية ذلك المسار، وليس دليلاً على أن كل نقل بيانات مسموح أصلاً.