Migration From V4

تحويل تعديلات القائمة

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

في الإصدار 4، يمكن استخدام طريقة threatListUpdates.fetch لتنزيل القوائم. في الإصدار 5، يمكن التبديل إلى طريقة hashLists.batchGet.

يجب إجراء التغييرات التالية على الطلب:

1. أزِل العنصر v4 ClientInfo بالكامل. بدلاً من تقديم تعريف العميل باستخدام حقل مخصّص، يمكنك ببساطة استخدام عنوان User-Agent المعروف. مع أنّه ليس هناك تنسيق محدّد لتقديم تعريف العميل في هذا العنوان، نقترح تضمين معرّف العميل الأصلي وإصدار العميل مفصولَين بمسافة أو شرطة مائلة.
2. لكل عنصر ListUpdateRequest من الإصدار 4: * ابحث عن اسم القائمة المقابل من الإصدار 5 في القوائم المتاحة وقدِّم هذا الاسم في طلب الإصدار 5.
   • أزِل الحقول غير الضرورية، مثل threat_entry_type أو platform_type.
   • يتوافق الحقل state في الإصدار 4 مباشرةً مع الحقل versions في الإصدار 5. يمكن ببساطة إرسال سلسلة البايت نفسها التي سيتم إرسالها إلى الخادم باستخدام الحقل state في الإصدار 4 من خلال الحقل versions في الإصدار 5.
   • بالنسبة إلى قيود الإصدار 4، يستخدم الإصدار 5 نسخة مبسطة تُعرف باسم SizeConstraints. يجب حذف الحقول الإضافية، مثل region.

يجب إجراء التغييرات التالية على الردّ:

1. يتم ببساطة استبدال enum ResponseType في الإصدار 4 بحقل منطقي اسمه partial_update.
2. يمكن الآن أن تكون قيمة الحقل minimum_wait_duration صفرًا أو يمكن إغفاله. وفي حال كان كذلك، يُطلب من العميل إرسال طلب آخر على الفور. يحدث ذلك فقط عندما يحدّد العميل في SizeConstraints قيدًا أصغر على الحد الأقصى لحجم التحديث من الحد الأقصى لحجم قاعدة البيانات.
3. تتطلّب منطق فك ترميز تجزئات Rice-Golomb إجراء تعديلَين أساسيَّين:
   • الترتيب حسب الأهمية والترتيب: في الإصدار 4، تم ترتيب الرموز الهاش المعروضة كقيم حسب الأهمية. في الإصدار 5، يتم التعامل معها كقيم big-endian. بما أنّ الترتيب المعجمي لسلاسل البايتات يعادل الترتيب الرقمي لقيم Big-Endian، لم يعُد على العملاء تنفيذ خطوة ترتيب خاصة. يمكن إزالة الترتيب المخصّص من الأقل إلى الأكثر أهمية، مثل الترتيب الوارد في تنفيذ Chromium الإصدار 4، إذا تم تنفيذه سابقًا.
   • أطوال التجزئة المتغيرة: يجب تعديل خوارزمية فك التشفير لتتوافق مع أطوال التجزئة المختلفة التي يمكن عرضها في الحقل HashList.compressed_additions، وليس فقط طول التجزئة المكوّن من أربعة بايتات والمستخدَم في الإصدار 4. يمكن تحديد طول قيم التجزئة التي يتم عرضها في الردّ استنادًا إلى HashList.metadata.hash_length الذي يتم عرضه من hashLists.list. بدلاً من ذلك، يشير اسم قائمة التجزئة المطلوبة أيضًا إلى أحجام التجزئة المتوقّعة التي يتم عرضها من القائمة. يمكنك الاطّلاع على صفحة قاعدة البيانات المحلية للحصول على مزيد من التفاصيل حول قوائم التجزئة.

تحويل عمليات البحث باستخدام رموز التجزئة

في الإصدار 4، يمكن استخدام طريقة fullHashes.find للحصول على تجزئات كاملة. الطريقة المكافئة في الإصدار 5 هي طريقة hashes.search.

يجب إجراء التغييرات التالية على الطلب:

1. يجب أن تكون بنية الرمز البرمجي على النحو الذي يتيح إرسال بادئات التجزئة التي يبلغ طولها 4 بايتات فقط.
2. أزِل عناصر ClientInfo الإصدار 4 بالكامل. بدلاً من تقديم تعريف العميل باستخدام حقل مخصّص، يمكنك ببساطة استخدام عنوان User-Agent المعروف. مع أنّه ليس هناك تنسيق محدّد لتقديم تعريف العميل في هذا العنوان، نقترح تضمين معرّف العميل الأصلي وإصدار العميل مفصولَين بمسافة أو شرطة مائلة.
3. أزِل الحقل client_states. لم يعُد ذلك ضروريًا.
4. لم يعُد من الضروري تضمين threat_types والحقول المشابهة.

يجب إجراء التغييرات التالية على الردّ:

1. تمت إزالة الحقل minimum_wait_duration. يمكن للعميل دائمًا إصدار طلب جديد حسب الحاجة.
2. تم تبسيط العنصر v4 ThreatMatch إلى العنصر FullHash.
3. تم تبسيط التخزين المؤقت ليصبح مدة تخزين مؤقت واحدة. راجِع الإجراءات المذكورة أعلاه للتفاعل مع ذاكرة التخزين المؤقت.