الخلاصة

  • تنص RFC 8259 على أنه ينبغي أن تكون أسماء الكائن فريدة، لأن المستقبلين يختلفون عند التكرار: بعضهم يحتفظ بالزوج الأخير، وبعضهم يفشل، وبعضهم يعرض جميع الأزواج.
  • متى حوّل المحلل عدة أعضاء إلى خريطة ذات قيمة واحدة، فلن تعيد مراجعة المخطط أو السجل أو التوحيد القياسي العضو الذي حُذف.
  • يقع الحد القابل للدفاع عند الاستقبال: حفظ دليل على النص الأصلي، ومقارنة الأسماء بعد فك المحارف المهربة، ورفض الغموض قبل أي استخدام دلالي.

ما يصل كسلسلة لا يصل بالضرورة كخريطة

يحمل كائن JSON على الشبكة أعضاء مرتبين من أسماء وقيم. أما التطبيق فيتعامل غالبًا مع خريطة لا تسمح إلا بقيمة واحدة لكل اسم. لا يظهر الفرق ما دامت الأسماء فريدة. لكن تكرار اسم واحد يفرض قرارًا: الإبقاء على الأول أو الأخير، أو عرض الجميع، أو إعلان الخطأ.

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

لذلك لا تعني عبارة «تم تحليل JSON بنجاح» أن له معنى واحدًا. إنها تعني فقط أن محللًا معينًا أنتج نتيجة معينة.

الدقة المقصودة في RFC 8259

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

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

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

يحول I-JSON التوصية إلى شرط قبول

تضيق RFC 7493 المجال في ملف I-JSON: يجب ألا تحتوي الكائنات على أعضاء بأسماء مكررة. ويُحكم على التكرار بعد معالجة المحارف المهربة. قد تبدو كتابتان مختلفتين في الجسم ثم تتحولان إلى تسلسل Unicode واحد بعد الفك.

لذلك لا يكفي مرشح يبحث عن التطابق الحرفي في النص الخام. يجب أن يرى الفاحص كل اسم بعد فك ترميزه، من دون أن تسمح خريطة عادية بمحو التكرار أولًا. ويتيح I-JSON للمستقبل رفض الرسالة غير المطابقة أو تجاهلها، كما يمكن لبروتوكول أمني أن يطلب عدم الثقة بها.

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

المحلل الأول يتحول إلى صاحب قرار

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

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

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

استثناء JWS محدود ببنيته

تطلب RFC 7515 أن تكون أسماء معاملات JOSE Header فريدة. وعلى محلل JWS إما رفض الأسماء المكررة، وإما استخدام محلل JSON يعيد آخر عضو مكرر بحسب الترتيب المعجمي فقط. القاعدة تحدد البنية والسلوك معًا.

ولا تعني أن JSON عمومًا يعمل وفق «الأخير يفوز». فهي تخص معاملات رأس JOSE، ولا تمتد تلقائيًا إلى كل جسم API أو ملف إعداد أو حمولة JWS. كما أن صحة توقيع JWS تثبت علاقة تشفيرية بين البايتات المحمية والمفتاح؛ ولا تمنح وحدها إذنًا بتنفيذ العملية الممثلة.

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

التوحيد القياسي لا يسترجع ما فُقد

تعرف RFC 8785 مخطط JCS لإنشاء تمثيل حتمي لـJSON. لكنها تبدأ بتقييد المدخل إلى I-JSON، ومنع خصائص الكائن المكررة، ثم تسلسل القيم الأولية وفق قواعد محددة وترتيب الخصائص بصورة حتمية.

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

وفي تطبيقات التوقيع، ترتب RFC 8785 العمل على النحو الآتي: تحليل البيانات والتحقق من I-JSON، ثم التحقق من قواعد المجال المستخدم، ثم فحص التوقيع، مع إلغاء العملية عند أي فشل. قبول النحو، وصحة المعنى، وصحة التشفير تظل ثلاثة اختبارات مستقلة.

اختبر الطريق الكامل

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

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

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

المصادر