مدخلات صحيحة بمعانٍ مختلفة
قد يكون مستند JSON كائناً أو مصفوفة أو قيمة بسيطة. لذلك null صحيح حتى لو اشترط العقد كائناً. تتجاوز بعض الأعداد دقة الأعداد الصحيحة في JavaScript، ولا تفسر المحللات أسماء الخصائص المكررة بشكل موحد.
| مدخل توضيحي | قراءة الصياغة | الفحص المتبقي |
|---|---|---|
| {"ok":true} | صحيح. | هل تتوافق القيمة مع العقد؟ |
| {"ok":true,} | غير صحيح: فاصلة نهائية. | عالج الخطأ صراحة. |
| null | صحيح. | هل يسمح العقد بقيمة null؟ |
| {"id":9007199254740993} | عدد صحيح الصياغة مع خطر دقة في JavaScript. | استخدم سلسلة لهذا المعرف. |
| {"a":1,"a":2} | أسماء مكررة: تفسير غير موحد. | حدد سياسة رفض وطبقها. |
افحص كل مرحلة استقبال
- استخدم محلل JSON مصاناً ولا تستخدم eval. افحص حالة HTTP ونوع المحتوى المتوقع وحدود الحجم والمعالجة الصريحة للجسم الغائب أو غير الصحيح.
- تحقق بعد ذلك من العقد: نوع الجذر والحقول المطلوبة والقيم المسموحة والفرق بين الغياب وnull والصفر. احتفظ بالمعرفات الطويلة كسلاسل إذا نص العقد على ذلك.
- حدد عمق البيانات والموارد وسياسة الأسماء المكررة والأخطاء. لا تدرج النصوص المستلمة في HTML أو الاستعلامات دون حماية مناسبة.
احتفظ بأخطاء مفيدة دون كشف البيانات
اختبر الردود الجزئية وتغييرات الإصدار وUnicode. سجل أقل سياق لازم بدلاً من الأسرار أو الأجسام الكاملة. يجب ألا يتحول فشل الفك إلى نتيجة فارغة ناجحة ظاهرياً أو يوقف السلسلة كلها بصمت.
المراجع الأساسية
تسجيل أخطاء واجهة برمجة تطبيقات JSON دون تسريب البيانات.
قد يحتوي نص JSON على مُعرِّفات أو بيانات سرية أو بيانات شخصية. غالبًا ما يتطلب التشخيص نوع الحدث، والمسار، والنتيجة، ومُعرِّف الارتباط، وتفاصيل الفشل غير الحساسة، بدلاً من البيانات الكاملة.
- تصنيف الحقول وإخفاء الحقول غير الضرورية للتشخيص.
- اختبار تحليل البيانات وفشل المخطط باستخدام قيم اصطناعية.
- التحقق من عدم نسخ سجلات الأخطاء وعمليات التصدير للبيانات كاملةً.
المصدر الأساسي: ACSC and partners — Event logging and threat detection. المنهج المرتبط: اقرأ الدليل العملي.
مفاتيح JSON وذاكرة التخزين المؤقت المُخصصة.
نقطة مراجعة إضافية: مفاتيح JSON وذاكرة التخزين المؤقت المُخصصة. سياسة على مستوى التمثيل واختبارات للكشف عن تسريب البيانات بين الحسابات والمحتوى القديم بعد التغييرات.
- اختيار مدة الاحتفاظ: يميز RFC 9111 بين التوجيهات: no-cache يتطلب التحقق قبل إعادة الاستخدام، no-store يمنع تخزين HTTP ذي الصلة، وprivate غير المؤهل يستبعد التخزين المشترك. لا يضمن أي منها بمفرده سرية النظام.
- فحص المفاتيح: التحقق من الطريقة، وURI، والأبعاد التي تُغير التمثيل. يتعلق Vary بحقول الطلب؛ وليس بالتفويض. ابحث عن اللغة المحذوفة، وتفاوض التنسيق، وسياق الحساب في طبقات التطبيق.
المصدر الأساسي: IETF — RFC 9111, HTTP Caching. المنهج المرتبط: اقرأ الدليل العملي.
تقسيم API وصادرات متسقة
قد تسبب البيانات المتغيرة فقدان سجلات أو تكرارها.
- سجّل المرشحات والترتيب ومفتاح الفصل عند تساوي القيم. حدّد إن كانت API تقدم لقطة ثابتة أم مجموعة متغيرة. اختبر الإنشاء والحذف أثناء القراءة؛ وجود مؤشر لا يضمن تجميد البيانات.
- في AIP-158 تنهي قيمة next_page_token الفارغة القراءة، لا صفحة نتائج قصيرة أو فارغة. الصفحتان الافتراضيتان [A,B] و[B,C] تضمان أربعة صفوف وثلاثة معرّفات فريدة. اكتشف تكرار المؤشر دون تقدم واتبع اتفاق API المستخدمة.
- احفظ الدفعة بشكل دائم قبل تثبيت الاستئناف. أعد الدفعة المنقطعة بمعرّفات مستقرة وافحص الصلاحيات في كل طلب؛ المؤشر ليس إذناً للوصول. إذا انتهت صلاحية اللقطة، أعد البدء أو طابق وفق سياسة واضحة؛ لا تجمع حالات مختلفة بصمت.
حالة قبول قابلة للتكرار
مثال افتراضي: البيانات لا تصف عميلاً أو نتيجة مرصودة.
عرض بيانات الحالة
{
"page_1_ids": [
"A",
"B"
],
"page_2_ids": [
"B",
"C"
],
"next_cursor": "c2",
"empty_page_has_next_cursor": true
}القرار المتوقع
B مكرر. افحص الهويات وتابع المؤشر حتى بعد صفحة فارغة إن بقي مؤشر تالٍ.
إجراء التحقق
- حدد المرشحات والترتيب الثابت وهويات العناصر.
- اختبر التكرار وصفحة فارغة بمؤشر تالٍ.
- احتفظ بالمعرفات وشرط النهاية الحقيقي. قارن العناصر المستلمة والمعرّفات الفريدة؛ وسجّل تكرار المؤشر دون اعتبار صفحة فارغة ذات متابعة نهايةً للجمع.
هل يثبت العدد المتوقع للصفوف اكتمال التصدير؟
لا. يمكن لمعرّف ناقص وآخر مكرر أن يتعادلا عددياً. قارن المعرّفات والنطاق ووقت القطع وسجّل الفروق غير المحلولة.
المصدر الأساسي: Google AIP-158 — Pagination. المنهج المرتبط: اقرأ الدليل العملي.