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. بما أنّ الترتيب المعجمي لسلاسل البايتات يعادل الترتيب الرقمي للقيم ذات الترتيب الكبير، لم يعُد على العملاء تنفيذ خطوة ترتيب خاصة. يمكن إزالة الترتيب المخصّص من الأقل إلى الأكثر أهمية، مثل الترتيب الوارد في تنفيذ 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. تم تبسيط التخزين المؤقت ليصبح مدة تخزين مؤقت واحدة. راجِع الإجراءات المذكورة أعلاه للتفاعل مع ذاكرة التخزين المؤقت.