VPN वर्गीकरण को कैश करें, उसकी आयु दिखाई देती रखें
एक अवलोकन, उसकी ताज़गी और आपकी साइट की प्रतिक्रिया अलग-अलग दरों पर पुरानी होती हैं। अलग रखे जाने पर, कैश किया गया वर्गीकरण इस बारे में ईमानदार रहता है कि वह क्या जानता है।
कैश किया गया वर्गीकरण एक लुकअप बचाता है और कल की राय को आज के निर्णय में जमा देता है। असली तुलना कैश बनाम कैश न होना नहीं है: वह एक अवलोकन, उसकी ताज़गी और आपकी साइट ने जो प्रतिक्रिया चुनी है। इन तीनों के बीच की सीमा खो दें और एक अनुकूलन अपने आप नीति बनाने लगता है। सुधार बहीखाता है, बेहतर फ़ीड नहीं।
तीन अलग-अलग घड़ियों वाले तीन रिकॉर्ड
अवलोकन वह फ़ील्ड है जो आपको मिला, जिस फ़ीड से वह आया और उसके पीछे का डेटासेट संस्करण। ताज़गी कैश प्रविष्टि का एक गुण है: लुकअप कब चला, प्रविष्टि पर कब भरोसा करना बंद हो जाता है, और क्या अंतिम रीफ़्रेश ने कुछ लौटाया। प्रतिक्रिया वह है जो आपकी साइट इस अनुरोध, इस खाते या इस क्रिया के लिए इसके बारे में करती है। इन्हें अलग-अलग स्वामी बनाते हैं और ये अलग-अलग दरों पर क्षय होती हैं, इसलिए blocked नाम की एक पंक्ति इस भेद को नष्ट कर देती है।
| Record | Who owns it | How long it should live | Damage when it is folded into another row |
|---|---|---|---|
| The observation | the feed's operator | until a newer dataset version replaces it | a stale lookup becomes indistinguishable from a fresh one |
| Its freshness | the application | one request's tolerance for age | a failed refresh hides behind a cache hit |
| The response | whoever owns the site policy | until that policy is reviewed | a feed outage turns into an indefinite block |
दो घड़ियाँ विशेष ध्यान देने योग्य हैं। आपका लुकअप जब चला वह क्षण वह नहीं है जब प्रदाता ने डेटासेट प्रकाशित किया, और पंक्ति को बाद में पढ़ने वाले ऑपरेटर को पता होना चाहिए कि हर मान इन दोनों में से किससे आया। समाप्ति और रीफ़्रेश फ़ीड के प्रलेखित अपडेट मॉडल और गलत होने की लागत के अनुसार तय करें, कभी भी किसी दूसरी साइट से उधार लिए गए अंक के अनुसार नहीं।
फ़ील्ड रखें, फ़ैसला नहीं
MaxMind का अनाम IP पर दस्तावेज़ एक ऐसे फ़ीड का ठोस उदाहरण है जो अनाम VPN, होस्टिंग प्रदाता, सार्वजनिक प्रॉक्सी और Tor एग्ज़िट को अलग-अलग फ़ील्ड में बाँटता है। यह यह भी दर्ज करता है कि एक अपंजीकृत VPN सबनेट इसके बजाय होस्टिंग ध्वज के नीचे उभर सकता है। इसे एक ही बूलियन में चपटा करना उस एकमात्र हिस्से को फेंक देता है जिसे ऑपरेटर बाद में ऑडिट कर सकता था।
अनुमान की कोई भी दिशा सुरक्षित नहीं है। होस्टिंग लेबल यह सिद्ध नहीं करता कि सुरंग का उपयोग हुआ, और VPN ध्वज का अभाव यह सिद्ध नहीं करता कि ग्राहक और आपकी सेवा के बीच कुछ नहीं था। ये दो अलग दावे हैं, और एक बूलियन इनमें से कोई भी व्यक्त नहीं कर सकता।
प्रविष्टि को उस पते से बाँधें जिसे आपने सत्यापित किया
रिवर्स प्रॉक्सी के पीछे, एप्लिकेशन को वही ग्राहक-पता प्रबंधन उपयोग करना होगा जिसे परिनियोजन ने मंज़ूर किया। कॉलर द्वारा दिया गया फ़ॉरवर्डिंग हेडर कभी भी किसी और की कैश की गई प्रतिष्ठा नहीं चुन सकना चाहिए।
वह विफलता एक साथ शुद्धता की बग और सुरक्षा की बग है, क्योंकि हेडर को नियंत्रित करने वाला हमलावर एक विश्वसनीय प्रविष्टि विरासत में ले सकता है या किसी पीड़ित को खराब प्रविष्टि पर पिन कर सकता है। कुंजी उस कनेक्शन से निकालें जिसे आपके अपने ढाँचे ने समाप्त किया, और दर्ज करें कि कौन-सी व्युत्पत्ति उपयोग हुई। जब आगे कई प्रॉक्सी हों, तो श्रृंखला का दस्तावेज़ीकरण करें, न कि पहले विश्वसनीय दिखने वाले हेडर पर भरोसा करें। यदि श्रृंखला अस्पष्ट है, तो व्युत्पन्न कुंजी और अस्वीकार किया गया हेडर लॉग करें, क्योंकि घटना समीक्षा दूसरे के बारे में पूछेगी।
साक्ष्य का न होना स्वच्छ परिणाम नहीं है
टाइमआउट, विकृत प्रतिक्रिया और अनुपलब्ध डेटाबेस में से हर एक का अर्थ किसी सफल लुकअप से अलग है जो किसी चीज़ से मेल नहीं खाया। इन्हें अलग परिणामों के रूप में प्रस्तुत करें, और पहले से तय करें कि जब कोई साक्ष्य ही न हो तो संरक्षित क्रिया क्या करती है। केवल-पढ़ने वाला पृष्ठ और साइन-इन किए गए खाते की क्रिया वहाँ अलग नियमों का पालन कर सकते हैं।
सामान्य प्रमाणीकरण बनाए रखना, या समर्थित सत्यापन माँगना, आम तौर पर किसी व्यवधान को सर्वव्यापी अनुमति या पूरी साइट के लिए प्रतिबंध मानने से बेहतर उत्तर है। सीमित करें कि लुकअप कितनी देर चल सकता है, और रीफ़्रेश तूफ़ानों को उसी तंत्र से रोकें जिसका एकीकरण समर्थन करता है। जब व्यवधान के दौरान पुराना मान उपयोग हो, तो निर्णय के बिंदु पर उसे पुराना चिह्नित करें, और रीफ़्रेश की अंतिम विफलता को दिखाई देने योग्य बनाएँ ताकि लंबे समय तक चलने वाली खराबी स्वस्थ प्रविष्टि के रूप में न गुज़र सके। चुनाव जो भी हो, उसे वहाँ लिखें जहाँ नीति लागू होती है, लुकअप के बगल में टिप्पणी में नहीं।
प्रतिधारण उसी निर्णय का हिस्सा है: इस फ़ंक्शन को जो फ़ील्ड चाहिए और उनके पीछे का समीक्षा-निशान रखें, उससे ज़्यादा नहीं। IP कैश को ब्राउज़िंग इतिहास बनना ज़रूरी नहीं है।
चार मामले स्वीकारें, जिनमें एक सुधार भी है
ताज़ा परिणाम, समाप्त परिणाम, विफल लुकअप और बाद में सुधारा गया वर्गीकरण परीक्षण करें। हर एक अलग शाखा का अभ्यास करता है, और केवल अंतिम ही दिखाता है कि गलत प्रतिबंध को पूर्ववत किया जा सकता है या नहीं।
फिर पुष्टि करें कि सामान्य उपयोगकर्ता के पास गलत ब्लॉक के बाद समीक्षा माँगने का रास्ता है, क्योंकि फ़ीड कभी-कभी गलत होगा और कतार डिज़ाइन का हिस्सा है। चारों मामले नीति के स्वामी के नाम के साथ रनबुक में लिखें। डिज़ाइन अपना स्थान तब अर्जित करता है जब वह अनावश्यक लुकअप हटाता है और अनिश्चितता को अक्षुण्ण रखता है और निर्णय दिखाई देने वाले रूप से किसी व्यक्ति के पास रहता है।