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 يمكن إرسالها ببساطة في الإصدار 5 باستخدام الحقل versions.
   • بالنسبة إلى قيود الإصدار 4، يستخدم الإصدار 5 نسخة مبسطة تُعرف باسم SizeConstraints. يجب حذف الحقول الإضافية، مثل region.

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

1. يتم استبدال قائمة القيم المحدّدة ResponseType في الإصدار 4 ببساطة بحقل منطقي باسم partial_update.
2. يمكن الآن أن يكون الحقل minimum_wait_duration صفرًا أو محذوفًا. إذا كان الأمر كذلك، يُطلب من العميل تقديم طلب آخر على الفور. ولا يحدث ذلك إلا عندما يحدّد العميل في SizeConstraints قيدًا أصغر على الحد الأقصى لحجم التعديل مقارنةً بالحد الأقصى لحجم قاعدة البيانات.
3. يجب تعديل خوارزمية فك ترميز Rice للأعداد الصحيحة 32 بت. يكمن الاختلاف في أنّ البيانات المشفَّرة يتم تشفيرها بترتيب مختلف للبتّات. في كل من الإصدار 4 والإصدار 5، يتم ترتيب بادئات التجزئة ذات الـ 32 بت أبجديًا. ولكن في الإصدار 4، يتم التعامل مع هذه البادئات على أنّها تنسيق little endian عند الترتيب، في حين أنّه في الإصدار 5، يتم التعامل مع هذه البادئات على أنّها تنسيق big endian عند الترتيب. وهذا يعني أنّ العميل لا يحتاج إلى إجراء أي ترتيب، لأنّ الترتيب الأبجدي مطابق للترتيب الرقمي باستخدام تنسيق big endian. يمكنك العثور على مثال على هذا النوع من الطلبات في عملية تنفيذ الإصدار 4 من Chromium هنا. ويمكن إزالة هذا الترتيب.
4. يجب تنفيذ خوارزمية فك ترميز Rice لأطوال التجزئة الأخرى أيضًا.

تحويل عمليات البحث عن الرموز المجزّأة

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

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

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

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

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