الخلاصة

  • أعطى RFC 1558 مرشح LDAP الثنائي صيغة نصية بادئة؛ فالأقواس و& و| و! والمقارنات و* كانت بنية الشرط نفسه.
  • لم يكن المرشح إلا حقلًا واحدًا في SearchRequest؛ إذ بقيت نقطة البدء والنطاق والأسماء البديلة والحدود وقواعد المطابقة وضبط الوصول وتسلسل النتائج قرارات مستقلة.
  • طورت RFC 1960 وRFC 2254 وRFC 4515 العقد نحو LDAPv3 وUTF-8 وهروب الثمانيات. أما RFC 1558 فكان Informational ولم يناقش الأمن، ولا يثبت حادثة أو نشرًا أو ثغرة حالية.

الرموز المقروءة كانت تحمل سلطة التفرع

في RFC 1558، تعني (cn=Babs Jensen) مساواة. وتضع (!(cn=Tim Howes)) النفي أمام ذلك الشرط. أما (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) فليست جملة طويلة، بل شجرة: AND في الجذر، ثم مساواة، ثم OR يجمع مساواة مع مطابقة جزء من الاسم.

تكشف النجمة الحد بأوضح صورة. فالصيغة attr=* تسأل عن وجود السمة، والنجوم في (o=univ*of*mich*) تفصل أجزاء نمط فرعي. وإذا كانت النجمة أو أحد القوسين نفسها جزءًا من القيمة، طلب نص 1993 أن تسبقها شرطة مائلة عكسية. يمكن لمحرف واحد أن يوسع مجموعة المرشحين أو يبقى بيانات، بحسب طريقة دخوله إلى القواعد.

يثبت سجل Datatracker وسجل RFC Editor أن الوثيقة صدرت في ديسمبر 1993 بصفتها Informational ولم تكن معيارًا للإنترنت. وتتيح النسخة النصية مراجعة مستقلة، بينما تفصل صفحة التصويبات التصحيحات عن الأصل. وقال قسم الأمن صراحة إن المسائل الأمنية لم تناقش. لذلك لا يجوز تحويل الوثيقة بأثر رجعي إلى تقرير عن حقن أو اختراق أو منتج بعينه.

النص لم يكن طلب البحث كاملًا

كان RFC 1487 قد وضع Filter المشفر بـBER داخل SearchRequest إلى جانب baseObject والنطاق وسياسة تتبع الأسماء البديلة وحدود الحجم والوقت وخيار إرجاع الأنواع وحدها وقائمة السمات. ووفر RFC 1488 تمثيل قيم السمات في ذلك الجيل. وحّد RFC 1558 وجه Filter البشري، لا جميع هذه المدخلات.

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

يفصل البروتوكول الحالي في RFC 4511، ومعه سجله الرسمي، بين قبول البنية وتقييمها. يقيم الخادم المرشح لكل قيد إلى TRUE أو FALSE أو Undefined. ولا يصبح القيد مرشحًا للإرجاع إلا عند TRUE؛ ثم تحدد قائمة السمات ما طُلب منه، ويبقى ما يُعاد فعلًا خاضعًا لضبط الوصول. قد تؤدي سمة غير معروفة أو قاعدة مطابقة غير مناسبة أو قيمة assertion غير صالحة إلى Undefined.

والنتيجة ليست جوابًا واحدًا: قد تصل رسائل SearchResultEntry وSearchResultReference بعدد صفر أو أكثر، ثم رسالة SearchResultDone واحدة. تشير الإحالة إلى مساحة لم تستكشف بعد، وقد تصل خانة بلا قيم بسبب الطلب أو سياسة الوصول. المطابقة والإرجاع والاكتمال والمصادقة والتفويض والفعل اللاحق إيصالات مختلفة.

انتقل الهروب من المحارف إلى الثمانيات الدقيقة

احتفظ RFC 1960 بالصيغة البادئة عندما حل محل RFC 1558 بصفة Proposed Standard، وهو ما يوثقه السجل الرسمي. ثم حل محله RFC 2254.

أدخل RFC 2254 المطابقة الممتدة في LDAPv3 وسياق UTF-8، ومثّل الثمانيات الخاصة بشرطة عكسية ورقمين سداسيين عشريين. وتبين صفحته الرسمية موضعه في السلسلة.

تشترط RFC 4515 الحالية، كما يعرّفها سجلها، هروب ثمانيات * و( و) والشرطة العكسية وNUL، وتضبط UTF-8 الصحيح. في (cn=*\2a*) تظل النجمتان الخارجيتان عاملي substring، بينما تمثل \2a نجمة حرفية.

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

العقد المشترك لا يمنح تفويضًا مشتركًا

حقق النص المقروء فائدة حقيقية: صار من الممكن مراجعة الإعداد وتبادل القوالب بدل الاكتفاء بـBER غامض. لكن العقد المشروع كان تمثيل Filter بأمانة، لا تحديد الدليل أو نطاق البحث أو سياسة الوصول أو معنى النتيجة.

يوفر طرح Heng Lu حول المواصفة الأولية الدنيا والقرار المستقبلي المحلي عدسة تحريرية لهذا الحد. ويطلب Running-Code Primacy إيصالات المحلل والخادم اللذين عملا فعليًا. أما طبقات الواقع فتبقي النص والشجرة وBER والتقييم والوصول والنتيجة والفعل منفصلة.

لا تسمي المصادر حادثة أو منتجًا حاليًا أو تثبت تعرض بيانات أو تقيس التبني. كما أن تعاقب RFCs لا يثبت انتقال كل الأنظمة. جعل RFC 1558 المرشح ظاهرًا؛ ولم يجعل ظاهره حكمًا نهائيًا.

المصادر