الخلاصة

  • عامل FTP الأوامر USER وPASS وACCT بوصفها معلومات مستقلة للتحكم في الوصول. قبول خطوة كلمة المرور لا يثبت أن الدخول اكتمل أو أن كل عملية لاحقة مأذون بها.
  • كان 332 جواباً وسيطاً إيجابياً، وبعد أمر ملف كان يعني أيضاً أن الخادم احتفظ بالأمر وهو ينتظر الحساب. أما 532 فكان يعني أن الأمر طُرح جانباً ويجب إرساله من جديد بعد ACCT.
  • لم يحدد البروتوكول معنى عالمياً للحساب؛ فقد يكون سياق مشروع أو مورد أو تفويض محلي. ولا تثبت وثائق RFC أو سجل IANA انتشار الاستخدام أو السرية أو الدفع أو نجاح نقل بعينه.

جواب صحيح لم يصل إلى حالة الدخول

يرسل العميل USER، فيطلب الخادم كلمة المرور، ثم يرسل العميل PASS. إذا لم يلزم شيء آخر، يجيز RFC 959 الرد 230 User logged in. لكن الخادم الذي يحتاج معلومات حساب للدخول يرد 332 Need account for login.

الرقم الأول، ثلاثة، لا يعلن الفشل. لقد قُبل الأمر السابق، غير أن الفعل المطلوب موقوف حتى تصل معلومة أخرى. الخطوة التالية هي ACCT، لا إعادة كلمة المرور التي اجتازت مرحلتها.

تكشف هذه الوقفة فرقاً تطمسه واجهات ذات خانتين. إثبات سر مرتبط بمستخدم لا يقرر بالضرورة المشروع أو التخصيص أو نطاق الوصول المحلي الذي ستعمل الجلسة داخله.

جاء الأمر الثالث من اختلاف الحواسيب

أضاف RFC 385 الأمر في أغسطس 1972، وذكر أن أنظمة مثل TENEX احتاجت مواصفة حساب منفصلة، زيادة على المستخدم وكلمة المرور.

فرق النص بين ACCT وPASS. لم يكن الحساب مرتبطاً حتماً بـUSER، وكان يمكن أن يصل في أي وقت، بل أن يستخدم المستخدم نفسه حسابات مختلفة لنقل ملفات مختلفة. فقد يلزم لإتمام الدخول أو لعملية محددة لاحقاً.

لا تسمح كلمة account بافتراض حساب مالي أو سر ثان. حمل FTP سلسلة Telnet وترك معناها للنظام البعيد. مشروع، تخصيص موارد، مركز تكلفة أو مجال تفويض احتمالات محلية؛ لا يختار المعيار واحداً منها ولا يصنع هوية عابرة للمواقع.

تغيرت الأرقام وبقي السؤال

أدخل RFC 542 ACCT ضمن أوامر الوصول سنة 1973. استخدم مخططه القديم 331 Enter account للحساب المطلوب أثناء الدخول، و433 حين لا يمكن نقل ملف دون حساب صالح ويجب إعادة الأمر.

أعاد RFC 640 بناء الردود كي تستنتج البرامج الحالة التالية من الأرقام، بدلاً من تحليل نص يختلف من خادم إلى آخر. صار 3yz جواباً وسيطاً إيجابياً، وصار 5yz نهاية سلبية للطلب نفسه؛ وجُمعت المصادقة والمحاسبة تحت الرقم الثاني 3.

عندها صار 331 طلب كلمة المرور بعد قبول المستخدم، و332 طلب الحساب للدخول، و532 طلب الحساب لتخزين الملفات. لذلك لا يجوز تفسير أثر قديم بجدول أحدث؛ الرقم نفسه كان يسأل سؤالاً آخر في مرحلة سابقة.

احتفظ 332 بالقصد بينما أسقطه 532

يوضح RFC 765، ثم RFC 959، حالة ما بعد الدخول. يرسل العميل مثلاً STOR، ويقرر الخادم أن هذا التخزين يحتاج حساباً.

إن حفظ الخادم أمر STOR منتظراً ACCT رد بـ332. لا يزال القصد في حيازته، ويكفي أن يكمل العميل المعلومة. أما إذا أسقط الأمر فرد بـ532. قد يقبل الحساب بعد ذلك، لكنه لا يعيد إلى الوجود عملية حُذفت؛ على العميل إرسال STOR ثانية.

إذن الرمزان ليسا صيغتين لخطأ واحد. إنهما يثبتان موضع القصد المعلق. تحويلهما إلى استثناء عام «الحساب مطلوب» يمحو قراراً تنفيذياً: هل يرسل العميل المعلومة فقط، أم المعلومة والأمر الأصلي؟

لم يكن 532 قياساً لمساحة القرص

قد توحي عبارة storing files بأن الخلل في السعة. لكن RFC 959 يخصص 452 لنقص مساحة التخزين في النظام، و552 لتجاوز التخصيص في الدليل أو مجموعة البيانات الحالية.

غياب سياق الحساب، ونقص السعة، وتجاوز الحصة حقائق مختلفة. الأول يحتاج معلومة تحكم، والثاني مورداً، والثالث تغييراً في التخصيص أو السياسة. جمعها تحت «خطأ تخزين» ينتج علاجات خاطئة ويخفي ما إذا كان الأمر السابق ما زال قائماً.

بقي الاتصال بينما تبدل سياق الوصول

يسمح RFC 959 بأمر USER جديد على اتصال التحكم نفسه. يمحو ذلك معلومات المستخدم وكلمة المرور والحساب ويبدأ تسلسل الدخول من جديد. تبقى معاملات النقل، ويكمل نقل جارٍ تحت ضوابط الوصول القديمة.

لا يعمل الانتقال بأثر رجعي. لا يملك المستخدم الجديد البايتات التي تتحرك بالفعل، ولا ينتقل الحساب القديم تلقائياً إلى الأوامر التالية. ويمحو REIN المستخدم والحساب ويعيد المعاملات الافتراضية من دون إغلاق الاتصال.

لذلك لا يكفي رقم الاتصال في التدقيق. ينبغي معرفة آخر USER وACCT وREIN أو إعادة اتصال سبقت كل عملية. نجاح حساب في لحظة لا يثبت أنه ظل السياق النافذ لاحقاً.

دعم ACCT لا يعني طلبه في كل موقع

وضع RFC 1123 ACCT ضمن الحد الأدنى الذي ينبغي أن يدعمه العميل والخادم، مع الاستثناء المتعلق بما يسمح به نظام الملفات أو التشغيل. ضمن ذلك ألا يعجز عميل مبسط عن تمثيل حالة مشروعة.

لم يلزم كل خادم بطلب الحساب. فإذا كان الأمر معروفاً لكنه زائد في الموقع، أمكن الرد الإيجابي 202. القدرة على فهم مفردة البروتوكول ليست سياسة تفرض استعمالها دائماً.

ولا يزال سجل IANA لأوامر FTP وامتداداته يسجل ACCT أمراً أساسياً للتحكم في الوصول ويرجع إلى RFC 959. يثبت السجل الاسم والتصنيف، لا الانتشار ولا معنى القيمة ولا اكتمال عملية.

حافظ البروتوكول على حقيقة لم تكتمل

لم يوحد FTP نظم الحسابات. منح الخادم حق طلب سياقه المحلي، ومنح العميل دليلاً على أن كلمة المرور لم تفشل، وأن قراراً آخر ما زال معلقاً، وأن الأمر السابق إما محفوظ أو مطروح.

الدرس ليس إحياء خانة قديمة في كل منتج. بل إبقاء إثبات الشخص، واختيار مجال الموارد، وقبول العملية نتائج منفصلة. إذا ضغطتها الواجهة في إشارة واحدة اسمها «authenticated»، عادت الحالة المفقودة في صورة أسرار مشتركة وبرامج خاصة وأخطاء لا يمكن تشخيصها.

المصادر وحدودها

تتكون الحزمة من RFC 385 وRFC 542 وRFC 640 وRFC 765 وRFC 959 وRFC 1123 وسجل IANA. تثبت هذه المصادر الدلالة والتاريخ، لا سلوك منتج بعينه ولا الاستخدام الحالي ولا السرية أو المحاسبة المالية أو نجاح الملف.