الخلاصة

  • يعني 480 أن الأمر مرفوض في حالة الاتصال الحالية، لا أنه محفوظ كي ينفذ تلقائياً بعد المصادقة.
  • يغيّر AUTHINFO هوية الجلسة وقد يغيّر قدراتها، لكن العميل هو من يعيد إصدار طلب المورد صراحة.
  • نجاح المصادقة لا يمنح تفويضاً شاملاً؛ فقد ترد السياسة المحلية على الطلب الجديد بالرمز 502.

الفرق بين 480 وطلب معلّق

يرسل العميل GROUP local.research، فيجيبه الخادم 480 Permission denied. بعد ذلك يستعلم العميل عن القدرات، يختار طريقة AUTHINFO، وينهي تبادل المصادقة بالرد 281 Authentication accepted. ومع ذلك لا تصبح المجموعة مختارة.

يلزم أمر ثانٍ هو GROUP local.research. الطلب الأول انتهى عندما وصل 480. لم يحتفظ به الخادم في طابور مخفي، ولم يربطه مسبقاً بأول بيانات اعتماد ناجحة تصل لاحقاً.

قد تخفي واجهة القراءة هذه الحدود وتعرضها كتجربة واحدة: اختر مورداً، سجّل الدخول، ثم تابع. أما على السلك فهناك ثلاثة أفعال مستقلة: محاولة رفضت، وهوية ثبتت، ونية أعيد إعلانها في سياق جديد.

الممارسة المبكرة أبقت الإعادة بيد العميل

وثّق RFC 2980 امتدادات NNTP الشائعة في التطبيقات القائمة. في الصيغة الأصلية لـ AUTHINFO USER وAUTHINFO PASS، كان 480 يطلب المصادقة، وقد يطلب 381 كلمة المرور، ويؤكد 281 قبول البيانات. بعد ذلك كان على العميل إعادة الأمر الأصلي الذي تلقى 480، ليعالجه الخادم معالجة عادية.

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

لكن الآلية القديمة حملت خطراً واضحاً: نص RFC 2980 على أن معلومات المصادقة كلها كانت تمر كنص صريح. سلامة حد الإعادة لا تعني سرية كلمة المرور. كان لا بد من طبقة حماية منفصلة.

المصادقة لم تبتلع التفويض

جاء RFC 4643 ليضبط AUTHINFO رسمياً، ويحافظ على USER/PASS للتوافق، ويتخلى عن SIMPLE وGENERIC، ويعرّف ملف SASL لـ NNTP. وهو يضع قيداً إدارياً أساسياً: الامتداد يصادق المستخدم، أما التفويض فتقرره سياسة الموقع.

لهذا لا يعد 480 بالوصول. إنه يقول إن استخدام الأمر أو المورد يحتاج إلى مصادقة و/أو تفويض. قد تزول العقبة بعد إثبات الهوية، وقد تبقى. يسمح RFC 4643 بأن يتلقى العميل المصدق 502 لأن المورد غير متاح له وفق السياسة المحلية.

دلالة 281 محدودة بدورها. فهي تثبت أن الخادم قبل تبادل المصادقة في هذه الجلسة. لا تثبت حق قراءة كل المجموعات أو النشر أو النقل بين النظراء، ولا تثبت أن صاحب الحساب ألّف مقالاً بعينه. وليست توقيعاً على المحتوى أو امتيازاً ينتقل إلى خوادم أخرى.

القدرات وصف للحظة، لا صفة أبدية

على العميل الذي يريد استخدام AUTHINFO أن يستعلم أولاً بواسطة CAPABILITIES. فالآليات المتاحة تعتمد على حالة الاتصال: قبل TLS أو بعده، قبل المصادقة أو بعدها، وفي نمط القراءة أو النقل.

عندما تنجح المصادقة، يجب أن يوقف الخادم إعلان AUTHINFO وأن يرفض محاولة AUTHINFO أخرى بالرمز 502. ويمكن أن تتغير قدرات أخرى، فتظهر أوامر أو موارد لم تكن معروضة للعميل المجهول. لذلك يحتاج العميل إلى صورة جديدة للقدرات قبل أن يقرر إعادة الطلب.

يبقى سرد آليات SASL كما هو بعد المصادقة لسبب مختلف: كي يقارن العميل ما رآه ويكتشف احتمال هجوم خفض نشط. بقاء السرد دليل على التفاوض، لا دعوة إلى مصادقة ثانية؛ فمدخل AUTHINFO نفسه اختفى.

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

لتبادل الهوية آلة حالات خاصة به

يجوز بدء AUTHINFO بعد 480 أو استباقياً ما دام معلناً. لكن لا يجوز للعميل تجاوز الخطوة الأولى إلا إذا رحّب الخادم بالمتابعة برد من فئة 38x. وأي رد آخر ينهي التبادل، فلا ينبغي إرسال مزيد من أسرار المصادقة.

كما لا يجوز للخادم أن يجيب AUTHINFO نفسه بـ480. وإلا صار الأمر المصمم لتلبية طلب المصادقة محتاجاً إلى المصادقة من جديد، فينشأ دوران بلا مخرج. أما 381 التاريخي فله معنى خاص: إنه يطلب الأمر المنفصل AUTHINFO PASS، لا مجرد تتمة بيانات للأمر السابق.

وبعد النجاح لا يمكن تبديل الهوية داخل الجلسة نفسها. تقديم هوية أخرى يستلزم اتصالاً جديداً. يحول ذلك دون اختلاط عمل بدأه طرف بامتيازات طرف آخر.

حماية الوصلة سؤال آخر

خصص NNTP الرمز 483 لنقص حماية الخصوصية. عرّف RFC 4642 انتقال STARTTLS، وبعده يعاد بناء حالة التطبيق ويعاد اكتشاف القدرات. قد يظهر USER/PASS داخل القناة المحمية فقط، وقد تتغير آليات SASL المتاحة.

إذن هناك أربعة أسئلة: هل الوصلة محمية؟ هل ثبتت الهوية؟ هل لهذه الهوية حق المورد؟ هل أرسل العميل الأمر من جديد في تلك الحالة؟ يجيب TLS وAUTHINFO وسياسة الموقع وإعادة الطلب عن أسئلة منفصلة.

ولا يصير المقال موثقاً من طرف إلى طرف بسبب ذلك. يحمي TLS وصلة NNTP واحدة. ويصادق AUTHINFO عميل الجلسة، لا مؤلف المحتوى بالضرورة، ولا يحمي كل مرحلة نقل لاحقة.

الرفض سجلّ، لا عملاً مؤجلاً

يعرض RFC 3977 مثالاً لمورد يتطلب المصادقة: أمر مجموعة، ثم 480، ثم تبادل هوية، ثم أمر المجموعة مرة أخرى. تكرار الأمر هو الدليل المباشر على أن المحاولة الأولى انتهت.

ينبغي للسجلات التشغيلية أن تحفظ الأمر الأول ورده، وقدرات ما قبل المصادقة، وحالة TLS، والآلية المختارة، ونتيجة الهوية، والقدرات الجديدة، والإعادة الصريحة، وقرار المورد النهائي. يمكن ربطها بمعرّف اتصال واحد، لكن دمجها في عبارة «نجح الدخول» يمحو سبب النتيجة.

قد تتطابق حروف الأمرين، إلا أن سياقهما مختلف: وقت آخر، وهوية أخرى، وقدرات أخرى. وقد ينجح الثاني، أو يحصل على 502، أو يواجه عطلاً مؤقتاً، أو لا يرسل أصلاً لأن العميل عدل عن قصده.

سجل IANA ينسق الأسماء ولا يمنح الحقوق

يسجل سجل IANA لمعاملات NNTP كلاً من AUTHINFO وSASL وSTARTTLS كقدرة مستقلة ذات مرجع معياري خاص. تتيح هذه اللغة المشتركة للطرفين وصف الانتقالات بدقة.

ولا يثبت التسجيل أن خادماً بعينه يدعمها حالياً، أو أن USER/PASS آمن في أي قناة، أو أن حساباً يملك حقاً معيناً. تبقى استجابة القدرات لهذه الوصلة والجواب عن الأمر المعاد هما الدليلين الفعليين.

الدرس الذي تركه NNTP أوسع من خدمة الأخبار: إذا رُفض عمل لنقص الهوية، فقد تصلح هوية أقوى السياق، لكنها لا ينبغي أن تستولي على حق إعادة العمل. يستطيع النظام أن يعرف من يتحدث، ثم ينتظر منه أن يقول مرة أخرى ما يريد فعله الآن.

المصادر