Migration From V4

बदलावों की सूची को बदलना

V4 में, सूचियों की पहचान थ्रेट टाइप, प्लैटफ़ॉर्म टाइप, और थ्रेट एंट्री टाइप के टपल से की जाती है. हालांकि, v5 में सूचियों की पहचान सिर्फ़ नाम से की जाती है. इससे, एक ही तरह के खतरे की जानकारी को कई v5 सूचियों के साथ शेयर करने की सुविधा मिलती है. पांचवें वर्शन में, प्लैटफ़ॉर्म टाइप और थ्रेट एंट्री टाइप हटा दिए गए हैं.

वर्शन 4 में, सूचियां डाउनलोड करने के लिए threatListUpdates.fetch method का इस्तेमाल किया जाता था. v5 में, hashLists.batchGet method पर स्विच किया जाएगा.

अनुरोध में ये बदलाव किए जाने चाहिए:

1. v4 ClientInfo ऑब्जेक्ट को पूरी तरह से हटा दें. क्लाइंट की पहचान के लिए, किसी खास फ़ील्ड का इस्तेमाल करने के बजाय, सिर्फ़ User-Agent हेडर का इस्तेमाल करें. इस हेडर में क्लाइंट की पहचान देने के लिए, कोई तय फ़ॉर्मैट नहीं है. हालांकि, हमारा सुझाव है कि इसमें सिर्फ़ ओरिजनल क्लाइंट आईडी और क्लाइंट वर्शन शामिल करें. इन दोनों को स्पेस या स्लैश से अलग करें.
2. हर v4 ListUpdateRequest ऑब्जेक्ट के लिए: * उपलब्ध सूचियों में जाकर, उससे जुड़े v5 की सूची का नाम ढूंढें और v5 के अनुरोध में वह नाम डालें.
   • threat_entry_type या platform_type जैसे गैर-ज़रूरी फ़ील्ड हटाएं.
   • वर्शन 4 में मौजूद state फ़ील्ड, वर्शन 5 में मौजूद versions फ़ील्ड के साथ सीधे तौर पर काम करता है. वर्शन 4 में state फ़ील्ड का इस्तेमाल करके सर्वर को भेजी जाने वाली बाइट स्ट्रिंग को, वर्शन 5 में versions फ़ील्ड का इस्तेमाल करके आसानी से भेजा जा सकता है.
   • v4 की शर्तों के लिए, v5 में SizeConstraints नाम का आसान वर्शन इस्तेमाल किया जाता है. region जैसे अतिरिक्त फ़ील्ड हटा दिए जाने चाहिए.

जवाब में ये बदलाव किए जाने चाहिए:

1. v4 enum ResponseType को partial_update नाम के बूलियन फ़ील्ड से बदल दिया गया है.
2. minimum_wait_duration फ़ील्ड की वैल्यू अब शून्य हो सकती है या इसे छोड़ा जा सकता है. अगर ऐसा होता है, तो क्लाइंट से तुरंत दूसरा अनुरोध करने के लिए कहा जाता है. ऐसा सिर्फ़ तब होता है, जब क्लाइंट SizeConstraints में, डेटाबेस के ज़्यादा से ज़्यादा साइज़ की तुलना में अपडेट के ज़्यादा से ज़्यादा साइज़ पर कम पाबंदी लगाता है.
3. राइस-गोलोम्ब कोडिंग का इस्तेमाल करके कोड में बदले गए हैश को डिकोड करने के लिए, दो मुख्य बदलाव करने होते हैं:
   • एंडियननेस और सॉर्टिंग: v4 में, दिखाए गए हैश को लिटिल-एंडियन वैल्यू के तौर पर सॉर्ट किया गया था. पांचवें वर्शन में, इन्हें बिग-एंडियन वैल्यू माना जाता है. बाइट स्ट्रिंग को लेक्सिकोग्राफ़िक तरीके से क्रम से लगाने का मतलब है कि बिग-एंडियन वैल्यू को संख्या के हिसाब से क्रम से लगाना. इसलिए, क्लाइंट को अब क्रम से लगाने का कोई खास चरण पूरा करने की ज़रूरत नहीं है. अगर आपने कस्टम लिटिल-एंडियन सॉर्टिंग को लागू किया है, तो उसे हटाया जा सकता है. जैसे, Chromium v4 में लागू की गई सॉर्टिंग.
   • वैरिएबल हैश की लंबाई: डिकोडिंग एल्गोरिदम को अपडेट किया जाना चाहिए, ताकि वह HashList.compressed_additions फ़ील्ड में दिखाई गई अलग-अलग हैश की लंबाई के साथ काम कर सके. ऐसा न हो कि वह सिर्फ़ v4 में इस्तेमाल की गई चार बाइट वाली हैश की लंबाई के साथ काम करे. जवाब में दिखाए गए हैश की लंबाई, hashLists.list से मिले HashList.metadata.hash_length के आधार पर तय की जा सकती है. इसके अलावा, हैश की सूची का नामकरण भी, सूची से मिले हैश के अनुमानित साइज़ को दिखाता है. हैश की गई सूचियों के बारे में ज़्यादा जानने के लिए, लोकल डेटाबेस पेज देखें.

हैश की गई खोजों को बदला जा रहा है

v4 में, पूरे हैश पाने के लिए fullHashes.find method का इस्तेमाल किया जाता है. पांचवें वर्शन में, इससे मिलता-जुलता तरीका the hashes.search method है.

अनुरोध में ये बदलाव किए जाने चाहिए:

1. कोड को इस तरह से स्ट्रक्चर करें कि सिर्फ़ ऐसे हैश प्रीफ़िक्स भेजे जाएं जिनकी लंबाई ठीक चार बाइट हो.
2. v4 ClientInfo ऑब्जेक्ट को पूरी तरह से हटा दें. क्लाइंट की पहचान के लिए, किसी खास फ़ील्ड का इस्तेमाल करने के बजाय, सिर्फ़ User-Agent हेडर का इस्तेमाल करें. इस हेडर में क्लाइंट की पहचान देने के लिए, कोई तय फ़ॉर्मैट नहीं है. हालांकि, हमारा सुझाव है कि इसमें सिर्फ़ ओरिजनल क्लाइंट आईडी और क्लाइंट वर्शन शामिल करें. इन दोनों को स्पेस या स्लैश से अलग करें.
3. client_states फ़ील्ड हटाएं. अब इसकी ज़रूरत नहीं है.
4. अब threat_types और मिलते-जुलते फ़ील्ड शामिल करने की ज़रूरत नहीं है.

जवाब में ये बदलाव किए जाने चाहिए:

1. minimum_wait_duration फ़ील्ड को हटा दिया गया है. क्लाइंट, ज़रूरत के हिसाब से हमेशा नया अनुरोध जारी कर सकता है.
2. v4 ThreatMatch ऑब्जेक्ट को FullHash ऑब्जेक्ट में बदल दिया गया है.
3. कैशिंग को आसान बना दिया गया है. अब कैश मेमोरी को सिर्फ़ एक अवधि के लिए सेव किया जा सकता है. कैश मेमोरी के साथ इंटरैक्ट करने के लिए, ऊपर दी गई प्रोसेस देखें.