Migration From V4

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Mengonversi Pembaruan Daftar

Tidak seperti V4, yang mengidentifikasi daftar berdasarkan tuple jenis ancaman, jenis platform, jenis entri ancaman, di v5, daftar hanya diidentifikasi berdasarkan nama. Hal ini memberikan fleksibilitas saat beberapa daftar v5 dapat memiliki jenis ancaman yang sama. Jenis platform dan jenis entri ancaman dihapus di v5.

Di v4, pengguna akan menggunakan metode threatListUpdates.fetch untuk mendownload daftar. Di v5, pengguna akan beralih ke metode hashLists.batchGet.

Perubahan berikut harus dilakukan pada permintaan:

1. Hapus objek ClientInfo v4 sepenuhnya. Daripada memberikan identifikasi klien menggunakan kolom khusus, cukup gunakan header User-Agent yang terkenal. Meskipun tidak ada format yang ditetapkan untuk memberikan identifikasi klien di header ini, sebaiknya sertakan client ID asli dan versi klien yang dipisahkan oleh karakter spasi atau karakter garis miring.
2. Untuk setiap objek ListUpdateRequest v4: * Cari nama daftar v5 yang sesuai di tabel di atas dan berikan nama tersebut dalam permintaan v5.
   • Hapus kolom yang tidak diperlukan seperti threat_entry_type atau platform_type.
   • Kolom state di v4 kompatibel langsung dengan kolom versions v5. String byte yang sama yang akan dikirim ke server menggunakan kolom state di v4 dapat dengan mudah dikirim di v5 menggunakan kolom versions.
   • Untuk batasan v4, v5 menggunakan versi sederhana yang disebut SizeConstraints. Kolom tambahan seperti region harus dihapus.

Perubahan berikut harus dilakukan pada respons:

1. Enum ResponseType v4 hanya diganti dengan kolom boolean bernama partial_update.
2. Kolom minimum_wait_duration kini dapat berupa nol atau dihilangkan. Jika demikian, klien diminta untuk segera membuat permintaan lain. Hal ini hanya terjadi jika klien menentukan batasan yang lebih kecil pada ukuran update maksimum di SizeConstraints daripada ukuran database maksimum.
3. Algoritme decoding Rice untuk bilangan bulat 32-bit harus disesuaikan. Perbedaannya adalah data yang dienkode dienkode dengan endian yang berbeda. Di v4 dan v5, awalan hash 32-bit diurutkan secara leksikografis. Namun, di v4, awalan tersebut diperlakukan sebagai little endian saat diurutkan, sedangkan di v5, awalan tersebut diperlakukan sebagai big endian saat diurutkan. Artinya, klien tidak perlu melakukan pengurutan apa pun, karena pengurutan leksikografis identik dengan pengurutan numerik dengan big endian. Contoh semacam ini dalam implementasi Chromium v4 dapat ditemukan di sini. Pengurutan tersebut dapat dihapus.
4. Algoritme decoding Rice juga harus diterapkan untuk panjang hash lainnya.

Mengonversi Penelusuran Hash

Di v4, pengguna akan menggunakan metode fullHashes.find untuk mendapatkan hash lengkap. Metode yang setara di v5 adalah metode hashes.search.

Perubahan berikut harus dilakukan pada permintaan:

1. Strukturkan kode agar hanya mengirim awalan hash yang panjangnya tepat 4 byte.
2. Hapus objek ClientInfo v4 sepenuhnya. Daripada memberikan identifikasi klien menggunakan kolom khusus, cukup gunakan header User-Agent yang terkenal. Meskipun tidak ada format yang ditetapkan untuk memberikan identifikasi klien di header ini, sebaiknya sertakan client ID asli dan versi klien yang dipisahkan oleh karakter spasi atau karakter garis miring.
3. Hapus kolom client_states. Fungsi tersebut tidak diperlukan lagi.
4. Anda tidak perlu lagi menyertakan threat_types dan kolom serupa.

Perubahan berikut harus dilakukan pada respons:

1. Kolom minimum_wait_duration telah dihapus. Klien selalu dapat mengeluarkan permintaan baru sesuai kebutuhan.
2. Objek ThreatMatch v4 telah disederhanakan menjadi objek FullHash.
3. Penyimpanan dalam cache telah disederhanakan menjadi satu durasi cache. Lihat prosedur di atas untuk berinteraksi dengan cache.