الخلاصة

  • تتجاوز صيغ Base64 الموسومة sloppy في RFC 9741 فحصًا محددًا: أن تكون البتات غير المستخدمة صفرًا. ويصف العامل .json القيمة بعد فك النص، لا صيغة تسلسل نصي وحيدة.
  • لا تؤثر الصيغة البديلة في الموافقة أو الحصة أو الفاتورة إلا عبر مفاتيح الخدمة وروابط سجلاتها الفعلية. تساوي البايتات وحده لا يثبت تجاوزًا للصلاحيات أو تحصيلًا خاطئًا.
  • يجب فصل قواعد التمثيل المقبول وهوية الأعمال والمدخلات المشمولة بالتوقيع، وربط كلفة التوافق بالوحدة التي تبيعها الخدمة وبالجهة المسؤولة عن تسوية السجلات.

موافقة واحدة لا تجيب عن سؤال الحصة

تخيّل خدمة تسمح لعميل بإجراء عملية على محتوى معيّن بعد الموافقة عليها. يصل طلب آخر يحمل المحتوى نفسه بصيغة نصية مختلفة. يرى فريق الاستقبال قيمة متطابقة، بينما يرى سجل الحصة مفتاحًا جديدًا. هل تُحسب وحدة أخرى؟ وهل تمتد الموافقة الأولى إلى الطلب الثاني؟ لا يمكن حسم السؤالين بالقول إن البيانات واحدة.

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

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

لذلك، فإن جمع كل هذه الحالات تحت كلمة «تكرار» قد يحوّل سياسة فنية إلى قرار غير معلن بشأن الصلاحيات والمال. المطلوب ليس معرفًا عالميًا يمحو كل فرق، بل تعريف للفرق الذي يهم في كل مرحلة. يساعد RFC 9741 على تحديد العلاقة الأولى، بين التمثيل النصي والقيمة، ويترك ما بعدها للمشغّل.

أين تختبئ الصيغة الإضافية؟

نُشر RFC 9741، من إعداد Carsten Bormann، في مارس 2025 ضمن مسار معايير IETF، وأضاف عوامل تحكم في CDDL لتحويل النص ومعالجته. يميّز بين .b64u و.b64u-sloppy لـBase64url بلا حشو، وبين .b64c و.b64c-sloppy لـBase64 التقليدي مع الحشو. تحذف صيغ sloppy التحقق من صفرية البتات الإضافية غير المستخدمة، لا بقية القواعد. كما لا يقيّد .json الفراغ غير المؤثر أو ترتيب تسلسل عناصر الخريطة. نشر المعيار ليس دليلًا على تطبيق أداة بعينها له.

يمكن رؤية الفرق باستخدام Zg وZh. أول ثمانية بتات في الصيغتين هي 01100110، أي البايت 0x66. أما البتات الأربعة المتبقية من المجموعة الثانية ذات الستة بتات فهي 0000 في الأولى و0001 في الثانية. هذا اشتقاق يدوي من توزيع البتات، وليس اختبار توافق نُفّذ على مدقق CDDL. عند استخدام قيمة تحكم واحدة تسمح بذلك البايت، يقع الفرق المعني بين العامل الصارم وصيغة sloppy في هذه البتات غير المستخدمة. والصيغتان التقليديتان مع الحشو هما Zg== وZh==.

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

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

النموذج ينجح في الفحص، ومفتاح الموافقة قد يبقى مختلفًا

تظهر العلاقة نفسها في JSON بصورة مألوفة:

{"account":"team-a","units":1}

{ "units": 1, "account": "team-a" }

يحافظ المثال على السلاسل الثابتة والعدد الصحيح الصغير 1، ولا يحتوي أسماء أعضاء مكررة. يتغير فقط ترتيب الأعضاء والفراغ غير المؤثر. يوفّر RFC 8259 الإطار النحوي، ويستبعد RFC 7493 الخاص بـI-JSON مشكلات منها تكرار الأسماء، ويوضح أن ترتيب الأعضاء لا يغيّر معنى الرسالة.

يستخدم .json التحويل الافتراضي من JSON إلى CBOR في RFC 8949، القسم 6.2. إنه يصف القيمة الناتجة، لا إصدارًا نصيًا وحيدًا. إذا حفظ نظام الموافقة النموذج كاملًا بوصفه مفتاح البحث، واستخدم التنفيذ القيمة المفكوكة، فلا يضمن نجاح فحص النموذج أن النظامين سيصلان إلى سجل الموافقة نفسه.

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

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

ثلاث هويات، وثلاثة أنواع من الأدلة

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

في JWS العادي ذي الحمولة المرمّزة بـBase64url، يعرّف RFC 7515 مدخل التوقيع باستخدام الرأس المحمي المرمّز، ثم نقطة، ثم الحمولة المرمّزة. تساوي القيم بعد تحليل JSON لا يمنح إذنًا باستبدال هذا المدخل بتسلسل جديد واعتباره الدليل الموثّق نفسه.

يمكن للتطبيق اختيار تمثيل قياسي لنموذج بياناته صراحة. يوفّر JCS في RFC 8785 تمثيلًا حتميًا داخل قيود مدخلاته، لكنه RFC معلوماتي من مسار النشر المستقل، لا التزام خفي في .json. لا يعمم هذا المقال قواعد JWS العادي على امتدادات الحمولة غير المرمّزة أو جميع أغلفة التوقيع.

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

الفاتورة تحتاج وحدة متفقًا عليها، لا مجرد مقارنة بايتات

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

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

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

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

قاعدة مشتركة رقيقة، وقرارات محلية واضحة

تقدّم مناقشة Lu Heng للمواصفة المشتركة الدنيا منظورًا يفصل القواعد الحتمية المشتركة عن ترتيبات الأعمال والاختيارات التشغيلية اللاحقة. تطبيق هذا المنظور هنا يعني ضبط قاعدة القبول دون جعل علامة المطابقة سلطة على السعر والإذن. وليس ذلك مراجعة منه لـRFC 9741 ولا مطلبًا محاسبيًا من IETF.

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

يحذر RFC 8610، القسم 5، أصلًا من الاعتماد على صحة مواصفة CDDL وآلية مطابقتها وحدهما دون دفاعات أخرى. كلما اتضحت علاقة النص بالقيمة، أمكن تحديد القرارات التي لم تتخذها. التوافق قد يكون مفيدًا، لكنه يترك عملًا بلا مالك إذا عومل نجاح الاستقبال كتسوية نهائية للهويات والحسابات.