Migration From V4

تبدیل به‌روزرسانی‌های لیست

برخلاف نسخه ۴ که لیست‌ها با تاپل نوع تهدید، نوع پلتفرم و نوع ورودی تهدید شناسایی می‌شوند، در نسخه ۵ لیست‌ها به سادگی با نام شناسایی می‌شوند. این امر انعطاف‌پذیری را در زمانی که چندین لیست نسخه ۵ می‌توانند نوع تهدید یکسانی را به اشتراک بگذارند، فراهم می‌کند. انواع پلتفرم و انواع ورودی تهدید در نسخه ۵ حذف شده‌اند.

در نسخه ۴، می‌توان از متد threatListUpdates.fetch برای دانلود لیست‌ها استفاده کرد. در نسخه ۵، می‌توان به متد hashLists.batchGet سوئیچ کرد.

تغییرات زیر باید در درخواست اعمال شود:

1. شیء ClientInfo نسخه ۴ را به طور کامل حذف کنید. به جای ارائه شناسه کلاینت با استفاده از یک فیلد اختصاصی، به سادگی از هدر معروف User-Agent استفاده کنید. اگرچه هیچ قالب از پیش تعیین‌شده‌ای برای ارائه شناسه کلاینت در این هدر وجود ندارد، پیشنهاد می‌کنیم به سادگی شناسه کلاینت اصلی و نسخه کلاینت را که با یک کاراکتر فاصله یا یک کاراکتر اسلش از هم جدا شده‌اند، وارد کنید.
2. برای هر شیء ListUpdateRequest نسخه ۴ : * نام لیست نسخه ۵ مربوطه را از لیست‌های موجود جستجو کنید و آن نام را در درخواست نسخه ۵ ارائه دهید.
   • فیلدهای غیرضروری مانند threat_entry_type یا platform_type را حذف کنید.
   • فیلد state در نسخه ۴ مستقیماً با فیلد versions نسخه ۵ سازگار است. همان رشته بایتی که با استفاده از فیلد state در نسخه ۴ به سرور ارسال می‌شد، می‌تواند به سادگی در نسخه ۵ با استفاده از فیلد versions ارسال شود.
   • برای محدودیت‌های نسخه ۴، نسخه ۵ از یک نسخه ساده‌شده به نام SizeConstraints استفاده می‌کند. فیلدهای اضافی مانند region باید حذف شوند.

تغییرات زیر باید در پاسخنامه اعمال شود:

1. ResponseType v4 به نام ResponseType به سادگی با یک فیلد بولی به نام partial_update جایگزین می‌شود.
2. فیلد minimum_wait_duration اکنون می‌تواند صفر یا حذف شود. در این صورت، از کلاینت درخواست می‌شود که فوراً درخواست دیگری ارسال کند. این تنها زمانی اتفاق می‌افتد که کلاینت در SizeConstraints محدودیتی کوچکتر از حداکثر اندازه به‌روزرسانی نسبت به حداکثر اندازه پایگاه داده تعیین کند.
3. منطق رمزگشایی هش‌های کدگذاری شده‌ی رایس-گولومب نیاز به دو تنظیم اصلی دارد:
   • Endianness and Sorting: In v4, the hashes returned were sorted as little-endian values. In v5, they are treated as big-endian values. Because lexicographical sorting of byte strings is equivalent to numerical sorting of big-endian values, clients no longer need to perform a special sorting step. The custom little-endian sort, like the one in the Chromium v4 implementation , can be removed if previously implemented.
   • طول‌های هش متغیر: الگوریتم رمزگشایی باید به‌روزرسانی شود تا از طول‌های هش مختلفی که می‌توانند در فیلد HashList.compressed_additions برگردانده شوند، پشتیبانی کند، نه فقط طول هش چهار بایتی که در نسخه ۴ استفاده می‌شود. طول هش‌های برگردانده شده در پاسخ را می‌توان بر اساس HashList.metadata.hash_length برگردانده شده از hashLists.list تعیین کرد. از طرف دیگر، نامگذاری لیست هش درخواستی، اندازه‌های هش مورد انتظار برگردانده شده از لیست را نیز نشان می‌دهد. برای جزئیات بیشتر در مورد لیست‌های هش، به صفحه پایگاه داده محلی مراجعه کنید.

تبدیل جستجوهای هش

در نسخه ۴، می‌توان از متد fullHashes.find برای دریافت هش‌های کامل استفاده کرد. متد معادل آن در نسخه ۵، متد hashes.search است.

تغییرات زیر باید در درخواست اعمال شود:

1. کد را طوری ساختار دهید که فقط پیشوندهای هش با طول دقیقاً ۴ بایت ارسال شوند.
2. اشیاء ClientInfo نسخه ۴ را به طور کلی حذف کنید. به جای ارائه شناسه کلاینت با استفاده از یک فیلد اختصاصی، به سادگی از هدر معروف User-Agent استفاده کنید. در حالی که هیچ فرمت از پیش تعیین‌شده‌ای برای ارائه شناسه کلاینت در این هدر وجود ندارد، پیشنهاد می‌کنیم به سادگی شناسه کلاینت اصلی و نسخه کلاینت را که با یک کاراکتر فاصله یا یک کاراکتر اسلش از هم جدا شده‌اند، وارد کنید.
3. فیلد client_states را حذف کنید. دیگر نیازی به آن نیست.
4. دیگر نیازی به وارد کردن threat_types و فیلدهای مشابه نیست.

تغییرات زیر باید در پاسخنامه اعمال شود:

1. فیلد minimum_wait_duration حذف شده است. کلاینت همیشه می‌تواند در صورت نیاز درخواست جدیدی ارسال کند.
2. شیء ThreatMatch نسخه ۴ به شیء FullHash ساده‌سازی شده است.
3. ذخیره سازی به یک دوره زمانی ذخیره سازی ساده شده است. برای تعامل با حافظه پنهان، به رویه‌های فوق مراجعه کنید.